colugomusic
patreon
Dev Log #55
🕑 Added 2021-08-06 00:00:06 +0000 UTCI am pretty happy with the progress I have made so far with implementing block references. I have finished the major architectural changes that were required and am now basically in the process of fixing all the scripts and re-connecting everything. Everything's coming together and seems to be working. Once I finish hooking up more parts of the UI I'll have some cool stuff to show.
There were a couple interesting issues/thoughts that have come to the surface during this process.
Block sizes
Blocks need to have a size associated with them for various reasons (e.g. so that they can appear in the block list and be previewed). If individual block references also have a size of their own, separate from the underlying block size, then I think it would be too confusing/annoying and it introduces a bunch of awkward issues to figure out.
After some deliberation I decided that a block reference is not going to have a size of its own. Instead the size is always part of the block's state, so if you have two references to the same block then resizing one block will resize both of them simultaneously.
This means I need to handle the following situation:
The blue block references both refer to the same underlying block. The user is dragging the right edge of the upper block reference to the right to make it bigger. The bottom block reference is also being resized, but soon its right edge will collide with the left edge of the orange block reference to the right of it.
The block reference needs to expand past that point no matter what, but the current layout system doesn't support this as blocks are never allowed to overlap on the same lane.
Therefore I think what I am going to do to address this is allow block references to "virtually" expand all the way to their target size, but automatically truncate them if they are colliding with another block:
Here the bottom blue block reference has a "target" right edge shown by the dotted line. The "actual" right edge is up against the edge of the orange block, and this is what the audio engine will see.
If a truncated block reference is then moved to accomodate its target size, it will automatically expand again:
To make this feel consistent I will probably also need to change the current block stamping behavior - Currently it is not possible to place a block over the top of an existing one, but now existing blocks references can auto-truncate themselves to make room. This will effectively be non-destructive behavior since each block reference will always expand back to its target size as soon as it has room. I think this will actually be an improvement over the current system where it's possible to accidentally shrink a block by dragging it up against another.
Parameter overriding
I mentioned before that creating variations among references to the same block (for example having two references to the same sampler block, but each playing at a different pitch) would be solved by the upcoming manipulator system. However the more I work on implementing the block reference system more I think there should also be a way to directly override parameters on a block. Technically this will be a bit of a hurdle but nothing more difficult than what I have already done, and the way I have architected block references so far supports implementing this.
UI-wise it's not so obvious. I'm imagining an interface where you can simply right-click on any toggle, slider or envelope to open a context menu and enable an "override" option and there would be a small, hopefully unobtrusive icon hovering over each overridden parameter. Here is an MS-paint idea of how a block reference might look with the amp envelope and pitch slider overridden:
Clearing the override would simply be a case of right-clicking again and disabling "override".
The border I drew around the waveform here is crude idea of how I might visually represent "this block has two or more block references associated with it, so edits you make will affect other parts of the song". In this case the block reference is in a group of 12.
Comments
Colugo Music
Some people are also reporting bugs on the Discord server: https://discord.gg/9ZW2UXM
Colugo Music
Thanks, I have logged the bug here: https://trello.com/c/tom4IBji/243-effect-block-becomes-uninteractible
Databroth
hey curious if you're taking in bug reports? I found that if you delete an fx lane and undo, you can no longer select the previously deleted lane
