[LV2] plugin bypass

[Stefano D'Angelo]

Premise: in my spare time, which now is quite limited but hopefully I
will have more during/after summer, I'm making yet another mono effect
processor using LV2 plugins, with an emphasis on guitar signal
processing, that means multiple MIDI-controllable effect chains,
built-in oversampling, "transitions" (fading) when switching effect
chains, mute, and bypass.

Just to say that I'm looking at the issue from this perspective.

2014-05-06 22:50 GMT+03:00 Robin Gareus <robin at gareus.org>:
> [Introduction]
>
> At the moment it's up to the plugin-host to handle bypassing of LV2
> plugins. In all LV2 hosts that I know this is currently implemented by
> literally bypassing audio and midi around the plugin which is problematic:
>
> Take a simple example: An amplifier, if that amp does not have a
> zero-gain, en/disabling the bypass will cause a jump in the
> signal-level. While in some cases x-fading on en/disable can work, it
> can also introduce artifacts - particularly in cases where a plugin
> introduces latency.

Totally agree, and that's why in my case bypass is not implemented
like that, but rather plugins in the active chain always run.
Inefficient? Maybe. Correct? Yes.

What are the problems I see doing bypass by skipping plugins?

1. Notion of running time is lost. Just think of (stupid example)
oscillators in parallel doing additive synthesis. You "bypass" one
then "unbypass" at a random time instant and the phase gets completely
fucked up (unless you are very very very lucky).
2. The "internal state" of the plugin is potentially wasted by
skipping data (think IIR filters), hence...
3. ... conceptually closer to activation/deactivation which we already have.

Now, I see value in RT-safe activation/deactivation and marking some
input control/whatever with a bypass flag so that a host can hide the
control if it understands it etc.

On the other hand, looong time ago I proposed some internal plugin
state saving mechanism, by which a host could actually make a copy of
a plugin instance, and one of the intended uses was to avoid glitches
etc. when modifying some sort of graph of plugin instances. Since it's
not in the ML archives any more, I quote myself shamelessly:

<quote>

2. Plugin instance duplication:

Moving plugins in a processing chain (but even more generically in a
network-like graph, I suppose) can cause unwanted noise (glitches,
clicks, etc.); a not too expensive solution to this problem could be
to duplicate the instances of moving plugins, running two branches
(one with the old configuration, the other with the new one) and
mixing the outputs so that the transition is smooth, then freeing the
branch with the old configuration.

The only way to duplicate plugin instances (and you need that, you
need to preserve state) I see is that the plugin does that for the
host (only the plugin knows about what's inside the handle), so the
idea is that the plugin should offer a function to the host which
returns a copy of a given instance (maybe we could let the host pass
allocator functions to the plugin as well to make it more general).
</quote>

and, answering to torbenh

<quote>
> neat indeed. but for it to be of use, it needs to work in RT context.
> basically it would need to be able to copy the state to a preallocated
> plugin instance.
>
> this if the plugin needs to allocate memory during this copy operation,
> we already need to pass in RTAllocators.

That's right, what about the plugin telling the host how much memory
it needs instead of going for RT allocators?

(yet I don't know if that would work with event queues and stuff like that...)
</quote>

I admit the hassle of implementing such a thing might be just too big
etc., I would not advocate it as of now, but maybe it's some sort of
starting point if anybody cares to give it some thought.

However I have the suspect I may not understand the real issue being
discussed, or that such issue comes from some other deeper problem
that has not been clearly stated...

Stefano