I think it is an architectonical problem and a question of “how clean is my code” (this is my field of expertise in professional life).
To provide such a functionality, the software has to have a clean object oriented design with a common base class for all the steps in audio processing, which could then (and only then!) be enhanced by a new path for transmitting “I have changed - everything from this point on needs to be recalculated” - information.
And it needs a “handoff” - mechanism, or at least to be able to support one quickly.
I have done a rudimentary study and analysis about “implementing a DAW with automatic background freezing” and I encountered a few obstacles, but nothing that can’t be solved with a little bit of effort.
As you said, sidechains and send channels would complicate things a bit, but with the “change notify” - mechanism it wouldn’t be that hard.
Let me explain a simple sidechain scenario, which can be scaled:
You have a VSTi which goes to channel 1 and an audio track on channel 2. Channel 1 output controls channel 2 compressor sidechain.
So:
Channel 1:
VSTi → Channel 1 + Sidechain of compressor in channel 2
Channel 2:
Audio playback → Compressor (with sidechain input) → Channel 2
Gives us the following “freeze points”:
a) Channel 1 VSTi
b) Channel 1 output (if more processing happens before that, otherwise it’s optimized away)
c) Possibly also the channel 1 sidechain send (if it’s modified, but pure level changes as in “send level” are irrelevant, because one multiplication per sample is virtually without any cost CPU wise)
d) Channel 2 audio file (may be optimized away, but processing may take place)
e) Channel 2 output post compressor
f) Channel 2 output (if necessary)
So, the “freeze points” are “connected” to each other in the same way their audio paths are connected - and if one “source” changes, the change is transmitted to the “sinks” and the sinks then know that “everything needs to be recalculated from now on”.
And to solve the problem about “change is accepted” (“undirtying”), one can always use a unique “change transaction id” which could be something as simple as an every incrementing 64 bit number or, if the developers can’t do a “f(x) → static x++” for some reason, a timestamp.
Meaning:
- A “source” doesn’t actually send “I have changed” to its sinks but rather a “my change transaction ID is 1377, if yours is lower then recalculate yourself”.
- The compressor with sidechain has, of course, two sources from which audio data and change transaction IDs come from - and if one changes, it knows “hey I’m invalid, I need to go online with my processing”
And no, VST interface changes are not necessary, the plugins can stay as they are. It’s all done by switching plugins on and off intelligently, utilizing preroll and postroll intelligently, too. Possibly going as far as recalculating the whole track on 1 - 2 cores in case of need.