Summary of planned features

Blockhead continues to steadily approach the "5% done" mark without ever getting there, due to the phenomenon of 2 new ideas coming up for every 1 that is implemented. This is a summary of my future plans. There are many things which are not listed here, these are just what's on the top of my head.

Quality of life updates

I will probably be working on these first three soon-ish, since i feel like workflow is still a little awkward in places where it doesn't need to be, and also these are things that people have been asking for for a while.

• Tracks should be able to be minimized so they take up less room (shrinking down to the height of the track header?) I still want to give some visual indication of the content of the track even when it is minimized so this would involve generating a thumbnail version of the content which would be rendered using thin, colored rectangles as is done in some other timeline-based software.
• Add a workspace map. Once I have a way to display content in a minimized view I'll be re-using it to implement a horizontal scrollbar at the top or bottom of the workspace which gives a visual overview of the entire workspace content.
• Lanes should be independently resizable, and tracks should allow multiple lanes to be expanded at the same time. I haven't figured out exactly how I want this to work yet but I don't want to lose the functionality of the "Focus" hotkey (default F) which expands the hovered item and pushes all the other lanes out of the way.
• Quick Search. I would like to add a hotkey which you can press and immediately start typing to quickly search for and add an instance of a particular thing.

Big Feature Updates That Will Take A Long Time

• Macro Blocks are still planned. For new people who haven't read my previous ramblings about it here is the elevator pitch:
  • A macro block will be a block which contains another workspace inside it.
  • You will be able to select any blocks on the workspace, right-click and "Create macro block" from the selection. This will be how we will be able to non-destructively convert a selection of blocks into a single re-usable block (e.g. for beats, loops etc.)
  • You can place a macro block just like any other block but also you will be able to open it open and edit the workspace inside.
  • The front-end of the macro block would act as a sort of window into the workspace inside.
  • Parameters of inner blocks would be modulatable from the front-end UI of the macro block.
  • A macro block can contain tracks, lanes and blocks just like a regular workspace.
  • A macro block can contain more macro blocks
  • Using the clone operation, a macro block can contain a reference to itself! (There would be a user-defined recursion limit)
• Block saving and loading. We should be able to save and load blocks to and from files (e.g. some kind of *.block file format). Blocks which depend on sample data (sampler blocks or macro blocks) would optionally store the associated sample data inside the block file.
• Parameter Overrides. We should be able to right-click on any parameter on a cloned block reference and mark it as "override", which would allow us to edit that parameter for that specific block instance without affecting the other blocks in the clone group. This can technically already be achieved using a manipulator but that can be a bit cumbersome.
• MIDI input and custom instrument system. The block list on the right-hand side is going to be thrown away completely and replaced with something quite complex. We will be able to build custom instruments by assigning blocks to a MIDI keymap. Playing instruments live into a MIDI-activated track would automatically insert corresponding blocks into the workspace (as opposed to inserting MIDI events like other DAWs).
• Block baking. Each block will maintain a list of other blocks which it depends on (for example an effect block depends on any blocks above it on the same lane which feed into it. When none of the blocks in the dependency tree are being edited (say 5-10 seconds have gone by without any edits), Blockhead will, in the background, render that block to a cache sample (similar to performing a manual bounce). Then any time the block plays back, as long as the cache is still valid, Blockhead will simply play back the cache sample data instead of re-rendering the block. Editing any block in the dependency tree will invalidate the cache. This system (especially in combination with recursive macro blocks) would theoretically allow very complicated signal chains to be set up and then played back with a very low CPU cost once everything is fully baked.
• On the fly waveform generation. The front-end UI of effect and synth blocks has been kept fairly empty because once block baking is implemented I want to display the resulting waveform of those blocks similarly to how sampler blocks currently look. This involves generating block waveform data dynamically, which is sort of already happening in the input panel but not in a way that can be easily re-used for blocks. I will likely try to rewrite things so that the same waveform generation code can be used in both places.
• Send/receive blocks. A "Send" block can be placed on a track to record any audio input that is fed into it from above. One or more "Receive" blocks can be connected to the Send block, to play back the audio somewhere else. The output of a Receive block can feed back into the corresponding Send block if it is simply placed above it on the same track, creating a feedback delay line. I already prototyped all this ages ago just to check that the idea actually works, but didn't have time to flesh it out properly.