Dev Log #36 (Patreon)

I've been working on a lot of different things over the past week. The data structure of projects has changed completely since v0.12.1 alpha so for a long time saving and loading has been broken. This makes testing things annoying so I finally got around to making it work again. The worst thing about the old project structure was the really stupid way I was storing effect rack data, but those are now removed in preparation for the new effects system so I was happy about not having to worry about that.

The block choke feature I wrote about in the previous post introduced some corner cases to be solved related to looping and block transitions so I ended up spending quite a bit of time trying to get it all working properly so that it doesn't cause any unexpected behaviour.

Dragging blocks around on a lane, resizing them and adjusting parameters all sounds pretty smooth now. Some operations which still cause clicks in the v0.12.1 alpha now crossfade properly (such as toggling mute on and off).

Unfortunately one thing that can still cause a nasty click during playback is dragging a block from one lane to another. Since lanes are actual relevant objects in the new engine, dragging a block onto a lane now causes it to change its place within the signal chain in a way that the existing declicking mechanisms don't account for.

I haven't had a proper think yet on how to fix this but it's probably going to be a hairy problem to solve so I will probably just make note of it as a known bug and approach it at a later date.

Currently I am working on rebuilding the various block UIs and re-connecting everything to the new backend. A lot of existing UI elements are being reused but I am taking the opportunity to address some existing bugs and make small improvements to the controls. One thing I added today is precision editing to the spinbox controls so you'll now be able to hold down shift or ctrl while dragging to manipulate the value in smaller increments.

In the new system many UI controls will now be defined by whatever sampler mode is currently selected. The Classic and Fudge samplers will now be entirely contained within separate plugins which Blockhead can read.

As well as dealing with the audio processing and waveform generation the plugins will also define the controls which should be available on the block when that sampling mode is selected. For example the "Fudge" plugin defines a "Speed" parameter which Blockhead will represent as a spinbox control in the block footer. At the moment those spinboxes are all hard-coded, but in the new system I'm building at the moment the following attributes are all defined by the plugin:

• The name of the parameter
• The min/max values
• How much to increment/decrement the value when the arrow buttons are pressed
• How best to interpret the mouse movement when the value is being changed by dragging the mouse up and down
• How to display the value on the screen (e.g. Amplitude will now be expressed in dB)

The plugins can also define additional boolean toggles to add. For example "Loop" and "Reverse" toggles are now dynamically added to the context menu based on the plugin rather than being hard-coded, as some future sampler modes might not support those.

One issue with having parameters be defined dynamically like this is that Blockhead has various interfaces for interacting with parameters which are expected to be present. For example the "block gestures" feature assumes that every sampler block has amp, pitch and sample offset parameters to manipulate. Also when toggling "mute" or "reverse" on a block with the keyboard shortcuts, Blockhead has to assume that those options actually exist.

Since the parameters are not hardcoded anymore Blockhead needs a way to check if they are present when the user tries to manipulate them using one of these alternate methods. To address this each parameter has a UUID and the plugin API defines a set of standard UUIDs that plugins should use if they define any parameter that is "amp-like", "pitch-like", "mute-like" etc. A lot of the time a concept like "amp" or "pan" or "pitch" is going to mean exactly the same thing from one sampler plugin to the next, but plugins are free to not use these UUIDs if they don't want to.

This also solves the second issue of having parameter data transferrable from one sampling mode to the next. Currently if you manipulate an envelope such as "Pitch" while in Classic mode, and then you switch to Fudge mode, the pitch envelope data remains, but it's just interpreted by the Fudge algorithm in a different way. To achieve this in the new system, when the user switches sampling mode Blockhead will check if the new mode defines any of these standard UUID parameters and point to any existing data if it exists.

At the deepest level the systems for moving all this data around are quite complex. All the data required by the sampler plugin needs to be prepared and managed in such a way that it can be updated on the fly but remains static for the duration that the plugin is processing it. What I have in place so far all seems to be working well so hopefully I don't hit any major snags.