Effects CPU usage when return bus has no signal passing through it?

Is my understanding correct that if a return bus is not actively being used, there will be no CPU usage consumed?

In other words, if I have a return bus with a whole bevy of effects, including multiple pitch shifters, convolution reverbs, etc. — but there is nothing sending to it at the moment and the volume is below a certain threshold = silence — those effects will not be engaged until something is heard?

Related to what I wondered earlier about silent tracks using CPU/resources in Any way to save on resources by "unloading" tracks in an event?

Unfortunately not.

Adjusting a sends to -oo dB does not virtualize the channels that contribute to that send; they’ll continue to be audible through the track’s non-send routing paths. Because the channels remain active, the sends will still have a signal to send; the fact that that signal is attenuated to silence just means they’ll send a signal of silence to the return bus, keeping the return bus’ effects from going idle.

1 Like

@joseph Thanks for clarifying.

And since there is NO current way to automate plugin bypass state ( Effect bypass automation function plans? - #15 by joseph ), there isn’t a straightforward workaround for momentarily disabling resources when return effects aren’t in use (some kind of “idle mode”), right?

Well… I supposed you could theoretically use transciever effects to do it. You’d need to put two transceiver effects on your return bus: One pre-fader effect set to transmit, and one post-fader effect set to receive, each set to a different channel. This would allow you to put all of your effects into events that contain no instruments of their own, but a similar pair of transciever effects on either side of a set of effects. Only the effects in the currently-playing event instances would consume resources, so you could change which effects chain affected the return bus simply by stopping one event and starting another.

Of course, you’d need to design the events so that they wouldn’t stop on their own, and you’d probably want to use some automation or modulation to ensure the effect changes when changing events wasn’t too jarring, but it would work.

I’m not sure if you’d call that a straightforward workaround, though.

1 Like

@joseph Ah, transcievers again! That’s very creative routing, and while not the most straightforward, knowing this option exists means I have an alternate path to be exhaustive with in case I run into resource usage issues. THANKS!