Dev log #24 - Background Tasks (Patreon)

Some tasks are run in a background thread to avoid blocking the interface. This currently includes loading sample data from files, bounce operations, generation of grain offset data, and eventually song rendering.

When a bounce is triggered the operation is placed on a queue and doesn't actually start until the previous bounce has finished. This means you should be able to bounce a block, place it in the workspace and then bounce the resulting block while the first bounce is still rendering. The second bounce will wait until the first bounce has finished.

Loading a sample or performing a bounce consists of two steps, loading the frames and then processing them. Frame loads are placed on one queue rather than happening simultaneously, which prevents Blockhead from generating hundreds of threads when loading a saved song.

When the engine finishes loading all the frames for a sample it then triggers a second "processing" task, on a second queue, to generate grain offset data and summary information. The grain offset data is used by the Fudge resynthesis engine and the summary information is used for better visual waveform rendering. These two operations are actually performed in the same pass which has the nice side effect of visually indicating how much of the sample has been processed.

Since the "processing" task is placed on a separate queue from the "frame load" tasks, other samples can continue to load their frames in the meantime.

Once we have VST support this will be more relevant since there is not really any limit on how slow VSTs can be. Currently you won't often notice things being queued up and waiting because the operations happen so quickly, but I want to support being able to bounce very large blocks and queue up arbitrarily large and expensive operations in the background, and even allow people to queue up multiple song renders if they want to. 

Song rendering can also be done in the background since it's basically just one big bounce, except it's going to the hard drive instead of to a sample. This presents a UI issue since I need some way to indicate that a song render is actually happening. And if the song render first has to wait for some bounce operation to finish then it will be sitting at zero percent which might be confusing, so we need some way to clearly show what other background tasks are currently running.

So right now I am writing a kind of task manager to replace what I currently have, and prototyping ideas for how to present it in the UI.