colugomusic
patreon
Dev Log #45
🕑 Added 2021-04-12 18:02:32 +0000 UTCI 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.
Comments
Rich Vreeland
it's like a whole new paradigm ... this is super inspiring !
Colugo Music
Another thing to think about if i enable this kind of "partial instancing" where some parameters are overridden is how to visually indicate which parameters have unique data associated and which are inheriting the underlying "base value". thanks for the feedback
Colugo Music
In my head part of the way macro blocks would work is it would automatically generate a list of modulatable parameters that exist inside the macro and then you would be able to edit the modulation for those parameters from the "front" of the macro (i.e. the level above). For example you could have a macro that contains a filter on the 2nd track, 3 lanes down. The block would have either a manual or automatically generated name like "Lowpass Filter #2" which would be visible from the level above and would be available from the macro's list of modulatable parameters. Unrelated but I like the look of the waveform editing in Logic's audio editor where you can just draw it in manually with the pencil tool. I have been thinking of adding something like that from the beginning but trying to make that available at the block level might be a bit bold. Also would like to add an "edit sample in external editor" feature if possible
Colugo Music
Yes i think the macro idea would be similar to the reaktor structure editor in a way
Rev Jragon
Perhaps a way to mitigate this, would be the ability to link automations to all instances of a sample (by choice, not automatically have the DAW do it all the time and not turn it off). But if not that, or as well as that, a copy and paste feature. Click and drag a highlighting box over all the points, right click and copy/ctrl+c and then paste it on the other ones. Little tedious, but better than nothing. This could be as well as the option to link specifically to the sample file, because you could want to do it to some samples, but make other samples different. And if it gets unlinked, it would be tight if it didnt delete the automation it made because of linking. So you could link, get the automation, unlink, and then change it a bit for variation.
This stuff was my first thought when I began experimenting with the DAW. The existing stuff conceptually aligns with Logic Pro’s sound file editor which is a sub component & separate from where the tracks & snippets are actually used & organized. If I could instantiate multiple copies of one “snippet” (which has all the existing automation, blocks, etc) on a separate “parent” track the potential for a full fledged daw begins. However there are lots of difficult questions to answer like: what automation & editing functionality can be applied to these “parent” tracks? Should I be able to apply plug-in effects the same way as with the “snippet editing” that exists now? Hopefully my unsolicited thoughts are welcome. This is awesome stuff :)
Damn, I get inspired just by watching those clips. Great implementation of the fx-block. Macro blocks remind me of the type of nesting you get in other modular enviroments that lends itself to performance. Might be good for big projects with alot going on — but 1 and 3 sounds immediately most intuitive to me.
