Blockhead dev log #12 (Patreon)

I went to bed still thinking about that bug I found yesterday and did my trick of lying there thinking about solutions instead of sleeping. So today I implemented a nice fix which didn't involve any complex rewriting of the block processing system as I feared I would have to do. I did however introduce a theoretical limit on the number of blocks that can be cleanly processed at once (currently set to 4096). Even if some mad person does try to do that it won't crash or anything, but it might glitch out. If someone's processing that many blocks at once they'd probably be hitting the limits of their CPU anyway.

I added a spring reverb to help test this out as it leaves a long tail which should be nicely gated when the playhead exits the block. The effect data will also be cleared so the next time that block is triggered the reverb won't have any tail left over from the last trigger, unless the block was re-triggered due to a looping section that exists entirely inside the block region, in which case the reverb isn't cleared.

Track effects, when I get to them, will work the way they do in other DAWs where they just continuously process (barring optimizations where the host tries to detect if the effect is not outputting anything).

This difference in behaviour between block effects and track effects was something I decided to do really early on so it's nice to see it finally coming together. One motivation for this design is that effects such as reverbs or delays that leave a long tail will be gated by default. You can really easily cut off the tail at exactly the moment you want just by resizing the block.

This spring reverb is based on the example reverb algorithm from madronalib, which apparently is the basis for Madrona Labs' Aaltoverb plugin. I think it sounds really nice. Madronalib is MIT licensed so I assume it is fine for me to use this algorithm in Blockhead though I will probably double check with Randy from Madrona Labs just to be sure.