Background rendering. why is it missing everywhere?

[solomute]

I remember some programs like sony vegas could do background rendering. It means when CPU is not loaded the software automatically starts rendering so that when you start playback it will be smooth because all filters are automatically passed by and you get stream from a temporary video file. I wonder why tracktion and other daws don't do background rendering into wav files for tracks so that instead of manually creating additional tracks and render tracks' outputs to wav files we could already have ready wav files which played back untill you modify any filtering on a track. This feature would save a lot of time and effort.

[solomute]

Also instead of creating each bus on a separate track,i would like to have one track with all 16 busses loaded. That track could be located on the top with drop down with all filters in a row with volume\pans and solo\mute in lower rows. Would save space a lot

[dRowAudio]

Also instead of creating each bus on a separate track,i would like to have one track with all 16 busses loaded. That track could be located on the top with drop down with all filters in a row with volume\pans and solo\mute in lower rows. Would save space a lot

I'm not quite sure what you're describing here but would creating your aux receive tracks and putting them in a folder help? That way you could just close the folder when you don't need to change the bus tracks.

[dRowAudio]

I remember some programs like sony vegas could do background rendering. It means when CPU is not loaded the software automatically starts rendering so that when you start playback it will be smooth because all filters are automatically passed by and you get stream from a temporary video file. I wonder why tracktion and other daws don't do background rendering into wav files for tracks so that instead of manually creating additional tracks and render tracks' outputs to wav files we could already have ready wav files which played back untill you modify any filtering on a track. This feature would save a lot of time and effort.

The video world is a bit different to the audio one and the demands on the system and requirements from the users are different.

One of the big problems is with plugins, you can't render a plugin and use it in real time at the same time so rendering would require a whole new version of the track (including all the plugins) to be loaded in the background whilst you render a section of the track that hasn't changed in a while.
This may be fine for some plugins but could cause more harm than good for resource hungry plugins.

Another issue is with causality. One of the big problems with pre-rendering is that most plugins (if they have any kind of delay in them, including any filters) will depend on the previous audio input to generate subsequent input. This means you can't just render a section of audio and expect if to seamlessly integrate with an unrendered section (think of a delay). This means that the only solution is really to render the whole track from the start.

Couple this with routing complexities such as racks, folders, submixes and aux send/receives and what you're really left with is a requirement to render whole tracks when they or any dependant tracks haven't changed in a certain period of time and are not likely to change in the near future. This is kind of what using our "Render Track" -> "Render to a new track" and then disabling the original does.

Agreed, we could improve this workflow a bit in the future perhaps to inform users when they haven't modified a track in a while (but how long is a while?) and ask if they want to render and disable the original.