[LV2] plugin bypass

[Luis Henrique Fagundes]

Hi,

Until seeing this thread, I was defending that bypass should be a host
feature. The reason is that people use one host with several plugins, there
are more plugins than hosts, so things that can be implemented in hosts
should be, so the plugin developer job would be easier. But the arguments
here are good, and now I'm convinced that bypass is a plugin thing, not a
host thing.

Still, in our environment (the MOD host with around 90 plugins selected by
our team) we have done the bypass at host level, and no musician ever
complained about the issues pointed here.

I like the idea of having the bypass port-prop, it would solve a big issue
for our software environment. I think a second feature would complement
this one: a host feature to bypass plugins, by literally bypassing audio
and midi, for plugins that explicitly support bypassing like this without
artifacts.

Luis


On Fri, May 9, 2014 at 12:47 PM, Stefano D'Angelo <zanga.mail at gmail.com>wrote:

> 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
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20140515/6f904118/attachment.htm>