Blockhead v0.42.0 alpha (Patreon)

INFORMATION FOR LINUX USERS

You now need at least glibc 2.38 to run Blockhead. This is a bit higher than what you needed before (2.31). There is no good technical reason for this change. I just fucked up. For extended details on the fuck-up see below. If you are using Ubuntu 24.04 then it will work because that's what I use to build on. For other distributions you will need to check your package manager to see which version of glibc you have, but if it's too low then you will probably get an error message about it on the command line when you try to run Blockhead. If you're using a relatively recent distro then you should be fine.

DETAILED INFORMATION ABOUT THE LINUX FUCK-UP (SKIP THIS IF YOU DON'T CARE)

I have three computers I use for Blockhead development: A Windows PC, a Mac Mini, and a laptop running Linux. For Linux builds I was using Ubuntu 20.04 as that has an old-ish version of glibc and so the binaries will run on a larger range of Linux distributions (when you build a binary on Linux and then distribute it to other Linux users, they will require at least the version of glibc that was used to build the binary.)

Doing Linux builds of Blockhead on that laptop is a bit painful because it can sometimes take up to an hour for a full rebuild (compared to 1 minute on Windows.) I think that is partly due to processor speed but also the laptop is probably running out of RAM during the build and having to go to swap instead.

I spent a couple weeks refactoring the codebase just to make the builds faster and while that helped a bit, building on that laptop was still taking around 40-50 minutes. So I decided to try to make good use of some of this Patreon money and upgrade to a decently high-spec laptop for Linux builds (I ended up going with a Lenovo X1 Carbon Gen 11.)

Unfortunately the network hardware in this thing is so new and fabulous that the version of the Linux kernel used by Ubuntu 20.04 doesn't actually support it, so I was without network access. I also tried installing Debian 11 instead since it uses the same version of glibc, but it had the same problem (and the touchpad also didn't work.)

I really can't be bothered to call up Lenovo technical support to organize a refund, post the laptop, and then shop for a different one and wait for it to arrive (I already had to wait several weeks for this one to arrive.) So I decided to take the less painful route and simply install Ubuntu 24.04 instead, which works perfectly (and builds take about 3 minutes now.) The upshot of this is that new Blockhead builds will require at least glibc 2.38 from here on out. Sorry!

CLAP AUDIO EFFECTS

Here is a list of CLAP-based audio effects, compiled by YankScally, with some incomplete information on how well they work in Blockhead.

https://docs.google.com/spreadsheets/d/1keqUNZ8DPRJsSAMQi4-L8JeLlActZuY6ol5MH6N2x2k

Non-comprehensive summary of things that are NOT currently supported:

• VSTs of any kind.

• Plugin parameter automation of any kind.

• Plugins which need multiple audio inputs to work (e.g. vocoders, or sidechain compressors).

• Plugins which have multiple audio outputs.

• MIDI/event based effects.

• Auxillary/send effect routing.

• Latency correction.

• Sandboxing (see below.)

CLAP PLUGINS EDITORS ON LINUX ARE A BIT BROKEN

With most plugins I have tried so far, the editor window is completely broken in one way or another and I'm not entirely sure it is Blockhead doing anything wrong. I am creating the editor windows using GTK rather than just creating raw X11 windows so perhaps that is my mistake. The LSP plugins in particular seem to be especially broken and will override the size of the window Blockhead creates for it to be really small, cutting off most of the UI. Any plugins implemented using the clap-juce-extensions library which includes Surge XT and Airwindows will, for me, just show a blank white window. I will try to reach out to some of these developers and send them a build of Blockhead for testing if they are interested in debugging these problems. From what I can tell from playing around with some other Linux DAWs that support CLAP, these weird issues relating to editor windows are pretty ubiquitous, so for now I'm not going to invest much time into debugging anything on my end unless there is something I am clearly doing wrong, or could easily do differently to fix things. I think that eventually it will be possible to iron out all the problems but it is just not something I want to be spending my time on at the moment. The good news is that aside from the editor windows, these plugins I've tested seem to be working well and will respond correctly to Blockhead's built-in parameter interface.

NO PLUGIN SANDBOXING

Blockhead doesn't do any plugin sandboxing. Plugin sandboxing is when plugins are run in a separate process so that if a plugin crashes or misbehaves then it doesn't take the entire DAW down with it. This is a bit challenging to implement but I will likely do it in the future.

OPENGL PLUGINS

It is a bit rare for a plugin host to be implemented using OpenGL and so it is probably not something that plugin developers are thinking about. Therefore they may assume that theirs is the only OpenGL context that exists in the current process. If a plugin does OpenGL calls but is not careful to make sure that its own OpenGL context is bound to the current thread, then it will cause problems in Blockhead. One thing I have seen is all the textures in Blockhead suddenly getting all messed up, but this is difficult for me to reproduce so it's not easy to tell if there's something I can do on Blockhead's end to circumvent it. Most OpenGL-based plugins I have tested have worked fine but if you see any graphical weirdness while using certain plugins then they're probably using OpenGL and misbehaving a bit. When plugin sandboxing is implemented, these problems will disappear completely because then plugins will be running in a separate process to Blockhead, and there will be no way for them to interfere with Blockhead's rendering.

NO MASTER BUS

You can currently only place CLAP effects on tracks. There is no master bus or send buses.

PLUGIN LOCATIONS

Blockhead only currently looks in the standard CLAP locations for plugins. There is no way to add additional search directories yet.

KNOWN QUIRKS

• On Windows, plugin editor windows are currently set to "always on top", meaning they appear on top of every other window of every application (not just Blockhead.) Ideally they should just appear on top of the Blockhead window but I don't think this is possible to achieve correctly without making Godot engine modifications so I will leave it for later and hopefully the current behavior is not too annoying.

• Resizing plugin editor windows should work if the plugin supports it, but it's generally about as janky as it is with VST plugins, due to the awkwardness of the various OS windowing systems. Note that some plugins will implement their own window resizing "handle" widget in the bottom-right corner of the window. Sometimes it's invisible. An example of a plugin that does this is Surge XT. If you grab onto that widget instead of the actual OS window frame then it tends to work a bit better.

• The track level meter currently shows the pre-fx signal, rather than the final post-fx signal.

PLUGIN SCANNING TIME

Blockhead scans for CLAP plugins in the background on startup, which might take a few moments. The more plugins you have the longer it will take. Your operating system or virus scanner may decide to scan the plugin files at the point when Blockhead attempts to load them which will slow things down even more. Most modern DAWs will create a database of working plugins that it finds so that future scans can be faster, but Blockhead doesn't do anything like that yet.

UPDATE NOTES

Feature: Top-level (non-macro) tracks can have CLAP-based effect plugins added to them. This is the first iteration of the CLAP support for Blockhead. There is a huge number of things still to do.

Update: Some modifications to the project state may now cause clicking artefacts if they happen during playback, where previously such modifications would be transitioned smoothly via project-wide crossfading. Unfortunately this is unavoidable in order to support rack-based realtime CLAP/VST effects. The existing plugin paradigm popularized by existing DAWs is simply incompatible with the project-wide state transitions that Blockhead wants to do. So the compromise I implemented is to allow certain operations to potentially click, as they might in other DAWs. These operations are:

• Changing the current workspace (including entering and exiting macros.)

• Adding and removing tracks.

• Adding and removing rack effects.

• Moving rack effects.

Update: The track header is now a footer instead which might take some getting used to.

Update: Track delete button was removed (now there is a context menu item instead.)

Bugfix: Possible crash when dragging a custom region in the input buffer.

Bugfix: Auto-saves directory is not saved to the config file if it selected using the browse button (instead of typing/pasting it in manually.)

Bugfix: Deleting the current workspace doesn't auto-select another one.

Links

Manual (WIP): https://docs.google.com/document/d/1y6je_g2oNnxClL1eXV20dcQpoyZEkek5LTxQPyEFT0w
CLAP plugins: https://docs.google.com/spreadsheets/d/1keqUNZ8DPRJsSAMQi4-L8JeLlActZuY6ol5MH6N2x2k
Known Issues: https://trello.com/b/MT1A3Zob/blockhead-issues
Discord: Blockhead (discord.com)
Development Videos: https://www.youtube.com/@colugo5172/videos