There are parts of tracks that are already done, and will stay the same. Could AT detect that and render that region, and play the recorded audio when it's played? When any changes are made, the program can revert back to the raw tracks. This can happen both on specific machines and in the timeline. For example, if a preset is applied to a machine and the user doesn't touch it for a few hours, the program can record that preset as a loop, and replace the audio output from the machine with the recorded track. In the timeline, if a region remains untouched for a few hours, the program can render the region, and replace the output audio of that region with the recorded track. This way, projects running on low-end machines don't crash as often, or overload the RAM or processor.
Comments (8)
This is a good idea. I remember that the early versions of Pro Tools (pre MIDI tracks) already had this kind of audio "cache". The only problem I see would be the amount of RAM necessary to hold the cached audio. For an on-line app running on a browser, it could be too much. That's the reason why even implementing a keyboard sampler (as opposed to the Machiniste) is problematic.
I was going to request the keyboard sampler... :(
The audio can be stored online in the Audiotool Cloud Sample Library, as a hidden, private sample?
Is a manual rendering still possible? A button such as "Finalize Section" button could let the user render each section they want saved manually. I do this sometimes on my own, like recording a loop, and replacing the selection with the loop track. Could that at least be simplified?
You can import a sample from the time-line (bounce) and substitute your audio chain/time-line regions with the sample, if you're absolutely sure you won't change that. A bit like the "bounce in place" function of other DAWs. I agree it's a bit convoluted, but maybe worth it in huge arrangements. I personally never have had the need to do this.
That's what I do currently. Can this be automated?
Thanks for suggesting this but I share the opinion that this is way too memory demanding and/or too complex to implement. I'd rather use more memory to speed up the devices.
We're going to tackle the overall performance-thing by other means this year and I believe it will get a lot better.
There will always be machines that cannot handle all tracks and there will always be complains, though.
The way he described it was a bit complex but this probably could be achieved in a much more simple way. Look at Soundtrap for example, they have a feature like this that renders tracks to audio, but it is a manual process that can be accessed via right click menu. This idea is pretty crucial due to every computers limitations and abilities, no matter how efficient a DAW is, there will always be lag.
A super simplified version of this is just one click temporary sample bouncing that can be deleted later down the line, but kept in the final track.