Dev Log #45 (Patreon)
Content
I had one very rough night where I couldn't sleep and ended up at 3am full of energy drinks working on the new effects system. I mentioned in the roadmap post that I already decided I was going to hold off on this but I ended up working on it anyway. Partly because everything I've been working on lately has been really boring so I wanted to actually do something interesting for a bit. This detour then turned into another detour and I also added a simple synth block.
Colugo on Twitter: "? https://t.co/XzEo3xl5ss" / Twitter
Colugo on Twitter: "https://t.co/sx5MMuZm4E" / Twitter
Colugo on Twitter: "https://t.co/h7hcVsqYjr" / Twitter
Getting the initial effects implementation done took a lot less time than I anticipated. I made some bold decisions while refactoring everything which have paid off and now adding new types of blocks is pretty easy. The effects and synth are all based on the same API as the samplers and there were only a few technical problems to solve when I added the effect blocks.
Blockhead abandons this skeuomorphic conceptual idea where a "device" is added to the project and then used to produce groups of related notes (for example in a synth melody or chord). Instead there's just these individual blocks which are responsible for doing one thing at one time in the song. The blocks themselves are extremely lightweight and can be copied around and manipulated very quickly, so it's not like having a bunch of VST instances loaded up or something.
At the moment the only way to control parameters is via the envelope editor which is clearly no good. What I want to end up with eventually is a large library of different types of control that can be used to manipulate parameters in various ways. I'm not sure yet if I will be bringing back the old knobs from the v0.12.1 effects system.
There's obviously a big problem to be solved in that there's no way in this prototype to manipulate a shared parameter and have it reflected across all related blocks. For example if you want to change the entire pitch of a melody which is made up of multiple blocks you have to edit the pitch on each block individually.
This problem already exists with sample blocks - if you have a drum hit that's copied and pasted a hundred times there's no way to modify all instances of it simultaneously.
There's actually a few different things I'm planning for the future that will address this and other related problems -
1. "Manipulator" blocks: An idea I touch on briefly in a previous post, where you can create special blocks which do not produce a sound but manipulate parameters on other blocks in various ways.
2. Macro blocks: Big stupid crazy idea exists in my head which I don't think I've talked about yet. A macro block will be a block that you can open up which contains its own workspace with its own tracks, lanes and blocks. You can then place them just like normal blocks and manipulate the internal objects of the macro through some interface on the front of the block. Macro blocks should also be able to contain other macro blocks.
3. Block "instancing" system: Which would be some system where instead of only being able to copy and paste blocks you should also be able to create some sort of reference block which points to the original. You would then be able to modify the shared parameters of the block from any instance but also override parameters on individual instances if you want.
Another thing that became more clear after adding the prototype effects is that the current design where only one lane on a track can be expanded at once is a little annoying when editing several blocks on different lanes, so I will need to have a think about how to mitigate this or whether I should be abandoning this design completely.