Obviously I am not a programmer so maybe this will not make sense.
I have seen mentioned that the decision was made with Ardour that plugins will always show the amount of DSP they will use regardless, for example when section of song/audio is not using specific plugins, they will still be using DSP.
I can understand that this is done so that DSP doesn’t all of a sudden go over the limit.
However, plugins that are turned off, also end up using DSP which I do not understand as much. Personally, I feel it would be nice if it was added that when plugins are off that they would not used DSP. Sometimes you want to have plugins added that are not necessarily being used / used all the time but you do not want them to be using up DSP.
Just a random example maybe some kind of metering plugins that you only turn on for specific purposes.
This will probably be something that someone can use as example against the request above, but this could also be a positive. If the above request is added, users can also be allowed to make the decision to use this with automation to turn specific plugins on / off at different sections of a song/audio to not use DSP. Again in this case it is the users choice to do this so they will have to take the responsibility if DSP goes over the limit.
Not something a user should use all the time, but nice that the option would be there.
Anyways, I am not sure if any other users agree with anything mentioned in this request.
Thank you to anyone who reads this
I have seen that some of my plugins may not be turning off correctly, and do report usage in the Plugin DSP load when bypassed, along with the DSP % in the upper right. The DSP is not reducing when the plugin is bypassed. I am thinking it was a poorly written plugin. There are lots of those around.
Perhaps these descriptions so not refer to the same thing:
Perhaps some plugins have a bypass control which is cross-faded so it won’t click, and leave GUI running so you can quickly switch the effect in and out for comparison.
In other words a plug-in with “bypass” is not necessarily the same as a disabled plug-in. That seems like a case of needing to know what your tools are doing, and something which seems obvious to me is perhaps not as obvious to others.
[quote=“Chris, post:7, topic:110599, username:ccaudle”]
and something which seems obvious to me is perhaps not as obvious to others.
[/quote] Take a look at this :
I disabled the RTA display to reduce CPU usage: (which continued to work when bypassed)
If a plugin has an bypass/enable control port (all VST3s have, some VST2 and some LV2 have) ardour will ask the plugin to bypass itself (the plugin will keep running, usually at a much lower DSP load).
As opposed to Ardour hard disabling the plugin this is click-free.
–
PS. The only way to hard bypass those plugins is with some Lua script.
Does that imply that Ardour still passes audio buffers to the plugin and calls the processing function for that plugin?
What happens to latency compensation calculations when a plugin is bypassed?
When Ardour hard bypasses a latent plugin, its latency is set to 0, and the signal directly passed though. When using pin-connections to bypass a signal around a latent plugin, the signal is delayed by the plugin’s reported latency.
When the plugin itself does the bypass internally, it’s up to the plugin.
Some plugins will publish a ‘bypass’ button which takes a very short path through the DSP. Perhaps they do a minimal amount of ramping in&out and then go into a minimal cpu mode. Our MPC Channel does this, because it’s a channelstrip plugin which is expected to live on many strips and it needs to use less cpu by default.
Other plugins continue to do a lot of work, even when soft-bypass. I think the AVA Multiband Compressor might be one of those cases, as that plugin is more of a mastering-style plugin, and you can bypass/unbypass the plugin and hear the effect without making a click. In fact you might still want to see the spectrum display while you are bypass/unbypassing it. So yes you might see a lot of persistent CPU usage from that plugin.
Some of our plugins do not expose a bypass control to the host, so it’s always a “hard” bypass if you do it from the mixer window. But inside the plugin there’s a “wet/dry” button which does a soft bypass so you can bypass the effect click-free. So in that case we will show 0% dsp when bypassed from the host, but 100% cpu usage when bypassed using the momentary bypass switch in the plugin (this is my personal favorite behavior, but your mileage may vary … you have to open the gui to access this)
And finally, there are many plugins that do not expose a bypass feature, internally or externally; all you can do is hard-bypass them from the DAW. In this case the DSP does go to ‘zero’.
It’s these kinds of decisions that often make a plugin manufacturer’s reputation “wow, brand X is really heavy on my cpu”; “wow, brand Y is really clicky when I bypass it, but it’s really light on my cpu” “wow, brand Z is light on the CPU and also doesn’t click in DAW A; but wow it clicks in DAW B” etc.
Harrison happens to make a lot of plugins for different use-cases, so you’ll see some variation.
-Ben
P.S. for those plugins that do expose a soft-bypass, it’s on our roadmap to also expose the hard-bypass as well, this would drop the cpu usage to zero even if the plugin likes to run in bypass. But this also adds a level of complexity to the user. Everything’s a tradeoff…
Linux Debian based distro / GTK based DE
Ardour 8.6
Okay, was not expecting all these responses after getting none
I just logged in so have not had a chance to read all of this so I apologize if this is overlapping / does not make sense.
I just tried a couple of plugins to confirm a little of what I read so far.
If I load for example LSP Chorus Stereo LV2 the DSP goes up and if I turn off the plugin in the mixer button, the DSP stays where it is.
(Ahh I just thought of why this could be…)
If I load up something like ZamVerb, which I think it was a VST3 which I will come back to, the DSP goes up and if I turn it off in mixer button then the DSP goes down as if it was not added at all. Back to VST3, not sure if anyone mentioned it but I think one of the “pros” to the VST3 format is that it is said to not use DSP when not being used, not sure if this has anything to do with my test results. Of course because I would rather use LV2, VST3 offers something like this
Anyways I am still confused, I was not aware how a plugin that is off in mixer is viewed/used by Ardour / DSP, but again I have not read all of the above yet.
This seems normal. When deactivating a plugin a reverb might cross-fade, an EQ will internally ramp gains for each band to zero, or a compressor decrease ratio to 1:1, etc. This can slightly increase DSP load while the plugin is being bypassed.
Then, once this click-free bypass is complete, the plugin can just pass though data without doing anything.
Turns out my test result / assumption about VST3 in the case of the ZamVerb was not really correct. I forgot that I also had LV2 versions of Zam plugins and they actually both do the same thing. Being that they come in both formats make them good for testing, I also used LSP plugins for testing in this case for the same reason.
So with the Zam plugins all the ones I tested did basically the identical thing. Inserted the plugins (some had pretty high DSP) and then when I used the bypass in mixer button the DSP went back down to my default Ardour percentage. Occurs with both VST3 & LV2 so had nothing to do with VST3 “benefits”, apparently whatever method Zam uses appears to be bypassing completely.
VST3 was said to always contain a bypass, I tested LSP VST3 vs LV2 to see if any difference but those had similar results to each other as well. The DSP stayed what is was when on or off for the VST3 and did the same with LV2 so no noticeable difference in plugin formats. I obviously didn’t test all of them so could still depend on the type of effect as well.
Alright well good to know that it varies from plugin to plugin for various reasons and as read above some could even be using some tricks