I’m not the original author of this post, but I could certainly benefit from this. Here’s an example scenario for me:
I frequently have 6-8 background vocal tracks on my recordings. Each of those will have inserts (typically a channel strip plugin), and, once I’m done comping and otherwise tweaking the individual tracks, I’ll freeze those with the inserts to save some CPU. These individual tracks are all going to a submix group track, which has the majority of the processing that relates to the background vocals on it. There are often some fairly heavy duty (in terms of CPU use) plugins here, essentially adding up to what would be a background vocals submix stem. Once I get the individual BGV panning set, and any individual track fader settings, potentially with some level automation if needed for different parts of the song, I am really only using the submix, but the individual tracks are still taking up resources. Depending on when I get to this point in my mix, I may keep things this way for a while.
At some point, however, my mix gets to a point where there is too much going on for my computer (Intel i7-5820k – from roughly 2014 – running Windows 10), even at the highest latency my MOTU 828x can handle, so I need to free up resources, and the BGV submix inserts can be taking up quite a bit of that. While I want to free up that resource, I’m not necessarily ready to commit to those settings permanently, either, even if the submix feeding the group track is highly likely to be final. Thus, what I do is render the BGV submix without any group track processing to a single audio track, then I replicate the BGV submix group track inserts and any other settings (e.g. fader level, gain/LPF/HPF) on that audio track.
At this point, though, the group track inserts are still taking up some resource. I don’t want to lose the group, just in case I change my mind on individual track settings for the submix feeding it later, but I do want to take it out of commission to free up the resources it is using, and the odds I’ll use it again are pretty slim. Ideally, I’d be able to disable the group track, as requested here. However, since that is not possible, I disable each individual plugin. (Bypass is not sufficient and will still figure into considerations such as plugin latency, as well as at least some CPU overhead – how much will depend on the plugins in question.)
What I generally do next is freeze the new BGV submix audio track to also take its inserts out of the picture while still making it easy to revisit those settings if I need to later (the odds on this can vary, depending on how late in my mixing process this occurs, but it is much more likely than needing to revisit the individual tracks that fed the submix). Most typically, my main work with this submix track going forward is just doing some fader automation.
Mind you this is only one example, though it is one that is applicable to almost every project I do. I could also add examples such as synth pad submixes, strings submixes, acoustic guitars submixes, etc. – it really depends how complex my project is and what sorts of plugins I’m using, and when my system gets to the point where audio is breaking up because Cubase can’t process the audio fast enough to fill sample buffers in time. But this consideration happens on almost every project at some point before I get to a final mix.
Beyond the (relatively minor?) workflow efficiency improvement this would make, I’d guess it may also make some (probably similarly minor) resource use improvement because simply disabling the inserts on the group track that is (at least temporarily) not being used may not free up all its overhead. For example, maybe the pre-section modules that are enabled might use some (probably minor) resources, even if no audio is passing through them? But it is really the workflow improvement that is of the most interest since, in addition to saving the time to disable the inserts, there is needing to hide the track from the project window and MixConsole window to keep it from cluttering things up.
interesting how workflows are different.