bitflipper
That feature will not, or I should say, cannot be implemented. Doing so would mean that it would be impossible to unmute a track during playback without dropouts or synchronization problems. Most users would find that unacceptable, since muting and un-muting tracks during playback is a very common practice.
Well, in Sonar/CbB that is not possible. But I do not exclude it will be implemented, if CbB will ever get any engine development (Sonar had no such development like 10 yeas long...). And such feature will take an hour to implement. Way simpler than implementing anticipative engine and can somehow compensate the age of current one.
There are 3 different plug-in states:
1. not loaded (no resource consumed)
2. loaded but not working (RAM is used, CPU is not used)
3. loaded and working (RAM is used, CPU is used).
With archiving you can get (1). With audio engine stopped you can achieve (2). Sonar keep everything in (3) otherwise. But what prevents switching to (2) when the result is muted? Nothing. Just current implementation in Sonar.
Note that:
* "switching" between (2) and (3) takes no extra CPU nor time, you just call "process" method on every buffer when required and no longer call it when that is useless.
* Sonar already distinguish between "automated mute" and "mute". Sure, for automated mute that is a bad idea.
* related to the previous point and "leaking" at other places when implemented, that feature introduce some plug-in specific trouble. Unexpected tails. Many plug-ins "remember" a part of previously processed sound and when asked to start again (un-mute), they will use wrong information. Not a big deal during normal audition. But not acceptable for automations and rendering.
You can guess at least one DAW which can save CPU on muted tracks, as default setting