plugin needs an automatable bypass

[cyrusadkisson]

plugin needs an automatable bypass. A must-have for serious DAW use.

[mikeoliphant]

That seems like something that should be handled by the DAW.

[cyrusadkisson]

Every other LV2 plugin has it but this one doesn't.

[mikeoliphant]

Every other LV2 plugin has it

That isn't true in my experience, but if it were it would seem to be a good argument for handling it globally in the DAW. Is there a specific use-case you have where bypassing by the DAW wouldn't work?

[cyrusadkisson]

I agree entirely. But I don't think that's how it works. I had to ask the guitarix guy to add bypass to some lv2 plugins (which he did) for this same reason. Maybe @x42 or @pauldavisthefirst can enlighten us?

[pauldavisthefirst]

There are numerous types of plugins where a host-implemented bypass will do the wrong thing (or at best, a sub-optimal thing). Reverbs, various kinds of EQ are the most common. Should the host silence the output of the plugin, or deliver silence to the plugin (results could be extremely different)?

[mikeoliphant]

In the case of this plugin, all I'd do is pass input->output or at most fade in/out.

[mikeoliphant]

I can see an argument for why a specific plugin might want to implement specific bypass behavior. But it seems that generic bypass behavior is best left to the DAW.

[pauldavisthefirst]

Ardour does provide a generic bypass.

But an automatable bypass is a plugin thing.

[mikeoliphant]

But an automatable bypass is a plugin thing.

I don't see why. If a plugin wants to do custom bypass, it can provide an automatable custom bypass parameter. That shouldn't preclude the DAW from allowing automation of a generic bypass.

Similarly, I provide Input and Output level controls for convenience (since it is key behavior for an amp plugin), but that doesn't mean that the DAW shouldn't be able to automate a plugin's input/output levels independently in a generic way.

[pauldavisthefirst]

A host cannot add parameters to a plugin.

So that would require that automation now has to take into account both the actual parameters of the plugin and "pseudo-parameters" created by the host.

Hosts are not going to do that.

[mikeoliphant]

A host cannot add parameters to a plugin.

It wouldn't be a parameter of the plugin.

So that would require that automation now has to take into account both the actual parameters of the plugin and "pseudo-parameters" created by the host.

Yes. Plugin parameters are just one of the the things a host needs to automate.

Hosts are not going to do that.

Here is how it works in Reaper:

[pauldavisthefirst]

Well, .... s/Hosts/Ardour/g

As noted, we provide a non-automatable bypass control. Since doing bypass correctly is always going to be done better by the plugin (even in Reaper :scream:) we resolutely refuse to provide an automatable version of this control.

We are happy to provide automatable gain control (which is not the same thing), mute and solo etc. But actual plugin bypass is a task best left to plugins and so we intend to leave it with them.

[mikeoliphant]

But actual plugin bypass is a task best left to plugins and so we intend to leave it with them.

Agree to disagree, I guess. The vast majority of the time, a plugin's implementation of bypass would be doing exactly the same thing as what the DAW would do.

[x42]

Is there a specific use-case you have where bypassing by the DAW wouldn't work?

In short the DAW does not know how to click-free bypass a plugin. Only the plugin has sufficient context.

e.g. a EQ usually ramps all gains to zero internally to bypass. A compressor internally ramps the ratio to one. A reverb may cross-fade. Latent plugins usually retain their latency when bypassed etc.

In almost all cases a DAW bypassing a plugin will not be click-free and cause artifacts. This is also why VST3 requires plugins to provide an automatable bypass.

[x42]

The DAW has only two options: [cross] fade, or direct hard bypass.

The former causes a comb-filter effect in most cases, and the latter a signal discontinuity (audible click). I hope we can agree that neither of those is acceptable for pro-audio in a studio and even less so live on stage.

[mikeoliphant]

The DAW has only two options: [cross] fade, or direct hard bypass.

In my (admittedly cursory) look at how lv2 plugins handle bypass, those that support it at all most commonly cross fade or hard bypass. As I said earlier on this thread, if I were to implement it in my plugin that's what I would do.

[pauldavisthefirst]

So no VST3 version imminent?

[cyrusadkisson]

So where did we land on this? Will you be able to add an automatable bypass to this plugin, @mikeoliphant ?

I also want to note that it's important the plugin be completely bypassed ("turned off" as much as possible) to conserve CPU. Some of the models are quite CPU-expensive this would allow me to run more instances of NAM LV2 in the same session if I'm, say, switching between guitar tones in the same song.

[x42]

I also want to note that it's important the plugin be completely bypassed ("turned off" as much as possible) to conserve CPU.

This is debatable. Ideally CPU load is constant. Then, when you enable a given effect in the middle of a live session there cannot be a CPU spike causing dropouts.

[mikeoliphant]

I remain unconvinced that this should be implemented in a plugin unless the plugin needs specific bypass behavior.

Automatable bypass and wet/dry controls in the DAW would give you exactly the behavior you are looking for (and would allow you to choose between "full" bypass or just running hot but silent). And it would work not just with this plugin, but any other plugin that doesn't already implement custom bypass behavior.

[x42]

Keep in mind that Dry/Wet causes a comb filter artifacts with many plugins. It is almost never the correct way to bypass an effect.

For some non non LTI effects (like this neural amp) one solution would be to fade the plugin's input to silence while them reversely adding the (delayed if latent) input to the output (rather than cross fade the output). Getting this right is what sets pro-audio effects apart.

[cyrusadkisson]

I also want to note that it's important the plugin be completely bypassed ("turned off" as much as possible) to conserve CPU.

This is debatable. Ideally CPU load is constant. Then, when you enable a given effect in the middle of a live session there cannot be a CPU spike causing dropouts.

When I manually disable NAM in Ardour, I see massive CPU savings. What am I missing?

[x42]

When I manually disable NAM in Ardour, I see massive CPU savings. What am I missing?

A proper bypass implementation from the plugin itself.

[cyrusadkisson]

@mikeoliphant Would you consider making a branch with an automatable bypass?

[mikeoliphant]

Would you consider making a branch with an automatable bypass?

I am unlikely to unless it either seems to be broadly preventing workflow across DAW software or there seems to be a clear need for a very plugin-specific bypass solution.

In your case, you seem to be primarily wanting to bypass plugins not in live use to save CPU. In that case, a DAW's automatable hard-bypass seems to be exactly what you want.

[cyrusadkisson]

@mikeoliphant At the end of this rope, I would ask you to look at who @x42 and @pauldavisthefirst are and then ask yourself if these are the people you want to stridently disagree with on anything remotely related to audio plugins, DAWs, etc.

Bc the alternative is I have to fork your repo and do this shit myself. Which sucks.

[pauldavisthefirst]

for the record, not comfortable with appeals to authority.