Spooky Development Update

Boo. This is a post to try to keep everyone up to date with exactly what I am doing at the moment since it has been a while since the last build. As a reminder I post occasional development updates in the form of youtube videos so if you want to listen to me awkwardly struggle to construct a complete sentence then you can do so here:

www.youtube.com/@colugo5172/videos

Script Blocks

I am currently working on adding Lua scripting to Blockhead. The first type of script is going to be in the form of the new "Script Block". I would like to take some up-to-date screenshots but unfortunately as I am writing this I am in the middle of refactoring things so here are some short videos I posted to twitter relatively recently:

https://x.com/ColugoMusic/status/1967558046647046376

https://x.com/ColugoMusic/status/1978818936876458302

And here is some basic documentation I have written so far:

https://github.com/colugomusic/blockhead-scripting/wiki/Blockhead-Scripting-Reference

This stuff is likely going to change a lot. Once the first version is done and people can actually start playing around with it then I hope people will have lots of feedback and suggestions. The basic API demonstrated in those videos is working very well so I'm pleased with what I have so far.

I could have finished the first implementation of this much quicker but I have decided to take the time to refactor things and clean up some old technical debt before releasing another build.

One thing I am quite happy with is the improvements I have made to Blockhead's thread management which was previously quite dumb. Blockhead does a lot of background processing and should now scale much better to properly utilize all your CPU cores. This is probably most noticeable with the baking system where previously Blockhead would only ever bake one thing at a time and is now able to do multiple baking operations in parallel.

I will likely be (temporarily) removing the CLAP-based effect racks while I focus on other things.

I think the per-track plugin effect rack has been my biggest regret since I started working on Blockhead. Not because the idea is bad, but because I ended up adding it much too early due to (unintentional) pressure from people asking about 3rd-party plugin support. This is entirely my own fault as when I would get asked the same question repeatedly about a particular feature I would make the mistake of prioritizing that thing over everything else, instead of just working on things in the order that makes most sense.

As a result I ended up spending about half a year working on CLAP support and plugin sandboxing and ended up with something which I'm not very happy with and that now causes a lot of problems during development.

The major pain of integrating 3rd-party plugins into Blockhead is that all these technologies such as VST or CLAP or whatever are completely object-oriented and event-based in their design, which makes a lot of sense when you consider the origins and motivations behind these technologies. But it is also fundamentally at odds with how Blockhead works, so I am always going to be trying to awkwardly shoehorn these objects into a system where they don't belong. This is not a show-stopper (the CLAP effect rack that I managed to get working is a decent proof of concept), but the integration requires careful consideration and adding it while Blockhead's core architecture is still in constant flux turned out to be very premature.

I have learned a lot while adding CLAP support and even ended up writing a generic open source plugin sandboxing system which does work pretty well and should be useable in the future when I get back to looking at 3rd-party plugin support.

Rethinking effect racks

One appeal of the per-track effect rack is it was a potential solution to a nagging question about the mixing and mastering workflow in Blockhead. For things like EQ and compressors and that sort of thing, I think Blockhead's block-based effect system doesn't make much sense and the more traditional DAW design is just a better approach.

It's common to want to apply an EQ or a compressor or some other mastering utility to an entire track with more or less fixed or rarely-changing parameter settings. (And if you actually do want to modulate the parameters over time then I think Blockhead's block-based effects are actually better for that purpose.)

While it's likely that the 3rd-party real-time plugin effect rack will return at some point in the future, I've been considering a different approach for the interim which is more inline with Blockhead's design, and can also nicely tie in with the new scripting system.

In this system every lane would have its own effect rack (I haven't thought at all about how the UI would look for this.)

This effect rack would work a bit differently though. Instead of being applied to the output audio of the lane, the rack specifies a list of postprocessing effects to be applied to each block on the lane, individually.

This postprocessing of each block is isolated from the other blocks on the lane. For example the reverb tail from Block 1 would not leak into the reverb of the next block on the lane, because each block actually gets its own individual reverb. The reverb tail would end at the right-hand edge of each block, just as how Blockhead's normal effect blocks work.

If you actually do want the effect processing of one block to "leak" forward into another then there would be two approaches:

• Bounce the related blocks into a single block.

• Just create another lane underneath and use a normal effect block instead.

Scripts can also be inserted into the effect rack, with the caveat that since scripts always do their processing offline, the script on Lane 2 would effectively make very block on Lane 2 an offline-only block (meaning you can only hear them once they have finished baking.)

In the case of something like an EQ I think this would achieve pretty much what a normal effect rack would achieve. Things like compressors or transient shapers might be a bit more interesting since the processing of each block is isolated and so the state of any internal envelopes wouldn't carry over from one block to the next.

A nice upshot of this is that it can be wired into the existing baking system so that you can really stack up a lot of effects without running into CPU usage issues.

In addition to the per-lane effect rack, it would be just as easy to add a per-block effect rack which can run either before or after the lane effects.

These are still just shower ideas at the moment but I am glad to finally have some possible ideas floating around for Blockhead's mixing and mastering workflow which don't involve just shoehorning in VST support.

...and Bug Fixes

As usual I will try to address all the major issues that have been reported in the interim between the previous build and the next one.

A few weeks ago I ended up deprecating the old library that I was using for saving and loading audio files and writing something entirely new which I'm now using in its place. I hope that this will finally resolve all the stupid platform-specific issues that we have been seeing related to saving and loading projects and import/export operations (mainly on macOS.) I believe a lot of these bugs were related to me not handling unicode correctly and then trying to patch the problem with lots of hacky fixes so I decided to just throw everything away and write things properly using everything I've learned.

Other than that I have pretty much put bug fixing on hold until I finish the first iteration of the scripting system but I will be spending some time before the next build to just work on bug fixes.