Dev log #31 - Vague roadmap (Patreon)

These are just the big tasks and features. The order of tasks might change. Smaller features not listed here will likely still be worked on in between everything else.

Massive refactoring Part 1

I'm slowly going insane because the design and scope of Blockhead is becoming much clearer in my head so I have a better idea of how the pieces are all supposed to fit together and how stupidly ambitious it all is. It's necessary to throw a bunch of old code and replace it with a better foundation which is what I'm doing now. I am decoupling a lot of GUI logic and improving the modularity of everything. The system which controls the project hierarchy of tracks, lanes, blocks and effects is being moved from GDScript to C++ in the process. Hopefully this will be done by the end of December.

Massive refactoring Part 2

The sample playback engines are going to be modularized. Currently there are two modes, "Classic" and "Fudge" which are hardcoded into the engine. These are going to be turned into plugins and an API will be developed to allow other developers to add their own playback engines (it would just be a dll that you can drop into the Blockhead folder).

Throw away the current effects system and replace it with something better

I have been designing a modular synthesis system similar to VCV Rack but more specific to Blockhead. This will power the effects and also the built in synthesizers.

An effect chain for a sample block as they currently exist would just be a modular rack that you can add to the sample block. The rack would have a built-in module that gets the output of the sample as it plays back which you can wire up however you like.

If I include at least one oscillator module at release then this automatically gives us a synthesis engine too. I will then add a way to add an empty audio block which contains just a rack with no sample attached, which will be the initial way of adding synthesizer blocks.

I will need to decide at this point if I am going to allow polyphony within a single block.

Probably around this point I run out of money and go get a job instead

Sadly it's not looking great. I received a bunch of Patreon subscribers back when I released the first alpha but since then the rate of new subscribers has slowed down massively. Currently I can pay about 1/4 of my monthly expenses with Patreon earnings so I am still losing a lot of money every month. Hopefully it does continue to grow and a huge thanks to everyone who has stuck with me so far! One mistake I made was buying a Mac Mini because there were so many people on twitter asking for a mac version so I was expecting an influx of subscribers but it didn't happen at all. A little lesson there about listening to vocal minorities.

Massive refactoring Part 3

Throw away the concept of a sample block and unify all audio blocks. A sampler module will be created for the modular rack and if the rack contains a sampler module then the current sample manipulation interface will be available.

On the surface, the process of adding a new sample to the workspace and manipulating it will be exactly the same as it is now. When a new "sample block" is created, it will actually be automatically creating a unified audio block with a sampler module already pre-added to the rack.

Individual channel manipulation and multi-sample blocks

The sample manipulation interface will be modified to add a way to manipulate the left and right channels individually. The will likely require changes to the sample playback engine API depending on exactly how I decide to implement it.

It makes sense to then allow multiple sampler modules to be added to the rack with a way to select the current sample to edit in the manipulation interface. This might involve adding a special view which has all the current samples displayed in a row within the block. Again adding just a simple sample block should be as easy as it is now so none of this should interfere with the current workflow.

Massive refactoring Part 4

There needs to be a way to edit multiple blocks at once. For example you might have a kick drum running all the way through your song and you want to edit every instance of it. There are a lot of different approaches I could take here and they all probably involve some fundamental changes to Blockhead's internals.

One idea is to do something similar to what the Godot editor does where if you create a duplicate of a resource it actually creates a reference to the original. Then any edits you make on the object are automatically reflected in all references. But you can also right click and select "Make unique" to break the link.

Saving and loading blocks

It should be possible to save and load blocks, give them names etc. This is already more or less there because it's essentially how the undo/redo system works when blocks have to pop in and out of existence. Saving blocks to disk should also be possible, with the option to save any referenced samples into the block file.

Track effects

Has been on the backburner for ages. The track rack will be similar to the block rack and will be using the same modular system, except the track rack runs continuously instead of only when the song is playing.