Hi, this is my first post
Does exist a way to automate the track state (active/inactive)?
I am using Ardour mainly for mastering and in my sessions each song is in a different track. I use several processors in each track. Usually: stereo processing, EQ, amplifiers and multiband compression. Also, I use a bus for the general limiter or other effects.
So, in this “linear scenario” (only a track at the same time) I’ve found that a lot of CPU is consuming while doing nothing. I know that I can automate the “bypass” of some plugins (for example the Calf Plugins wich I use), but it is a bit of a “tedious task”.
If it does not exist, could be a good feature request?
Cheers, and Happy New Year!
An extension of that idea would be to automatically stop processing on any track as soon as there was no active region supplying data to that processing chain. That idea might come adrift, though, if it meant cutting off a reverb tail that’s still audibly decaying at the end of a region.
I wouldn’t be surprised to find that there are horrible difficulties with this, in the way plugins behave when stopped and started.
We have no plan to ever automation active/inactive state.
You can “freeze” a track which will re-record it to disk with all the FX applied, and then replace the existing playlist for the track with the result, and disable all plugins on the track.
I wouldn't be surprised to find that there are horrible difficulties with this, in the way plugins behave when stopped and started.
Unfortunately it has become fashionable for almost all
DAWs on other OS to do this, with varying degrees of success (or more correctly, varying degrees of failure
, because, it inevitably does
wreak havoc with many plug-in processes - not just reverb tails - and leads to ugly combinations of hacks in the host / plug-in spec, and creative 'workarounds' in plug-ins, normally aimed at defeating it). Any 'stateful' processing (in other words almost any DSP) will react badly to being stopped and started, or more specifically stopped and started again with unrelated material. There is also the other 'statistical' effect which seems to make almost all 'standby' based power saving much less effective than it should be in theory (e.g how often are you diverted from using a computer, only to return at the precise instant that the machine spins down its disks and goes into standby, thereby ensuring it has spent maybe twenty minutes or more on full power, without being used, only to switch into standby at the precise moment it needs to be 'revived' - invariably using more power to do so again than it would have saved, had the standby function actually worked). The same tends to be true of plug-in power-saving schemes - there is much less CPU which can be safely 'saved' than it may first appear. Far better to design plug-ins and processing which are as efficient as possible at managing their CPU usage all the time