I've been asked 'why not just use supercollider', and the last time somebody did that, this went on hold a bit while I thought about it. But I'm more convinced than ever that this is a worthy exercise. I'm not discounting supporting external synths of course, but as an explanation: • On windows, I've had various problems trying to get SC to work. It's difficult to install, the UI is weird/broken. Last year during a workshop I failed to install it on 3 different machines. • I have to write stuff before I really understand it, and it's fun, regardless. I've already learned so much about audio programming. • I like the idea of tools that just work out of the box; a simple install and you are done. I believe any friction at all loses users. I haven't really played with Tidal Cycles to this day due to the amount of time I've wasted trying to get it installed/working. A big part of this project is making a toolkit of AV bits that just work. That's the hope anyway.

The bank holiday weekend looms, and perhaps with it a chance to build out this UI and make it functional ;)

I saw Fe on Hackernews the other day and it looks good

Trying to see how far I can get with mostly single header file libs :)

For CPU programming I think I'm going to start with a list of operations (UI) and maybe go to a node graph so I can make a render graph, but it's tempting to add a full VM, integrating Lua might happen at some point but Fe looks like a good option, I might also write my own VM again though

I've also experimented with Shadertoy; I have an automated download which works as long as shadertoys have been published with the API flag on. I'm still tweaking the details of how I manage the boilerplate code that is injected to support the shadertoy variables.

I'm in two minds about Fe; on the one hand I have already integrated Chibi Scheme, which has a lot of features, but on the other hand I like that Fe has a simpler FFI and is easier to hack.... Fe doesn't have tail recursion, etc. and things like that worry me because it's easier for a user to bring the system down. But I'm no lisper yet, so I don't have enough technical knowledge to properly understand the pitfalls.

To get a required header

Also using master from GitHub I had to modify the header slightly to get it build

I think it was also using a now deprecated standard library (experimental namespace)

I should have took notes I was trying to get my prototype running and didn't though :)

But when I revisit Zep I'll take note of the issues I ran into and can contribute fixes if necessary

They were all minor, but the CMake dependency was a little annoying

My current app isn't compatible with shader toy at all and I don't have plans to do so, but it is inspired by it, mostly I wanted to experiment with some new features in DX12 (might add a Vulkan backend later, but I wanted to get familiar with DX12) and I've started to try to support live coding and fast data driven iteration in anything I make

@Scott Anderson I understand. To be honest, I haven't looked at the single header build for a while; it probably needs updating. When I moved to modern CMake it became so trivial to integrate into other projects, I lost some interest in maintaining the single header build. I'll revisit that this week and decide what to do; mostly I'd like the single header build to go away and people just add Zep::Zep to their target library depenencies; which is a very easy way to go. But I know that the single header lib is preferred by some.

As you say, there are other choices. If you don't need the Vim keystrokes, or any of the other advanced features, the standard ImGui editor is a little easier to drop in.