[LV2] plugin bypass

[David Robillard]

On Tue, 2014-05-06 at 21:50 +0200, Robin Gareus wrote:
> Hi David, LV2-devs,
> 
> This follows a discussion Fons (CCed) and I (and some others) had at the
> LAC:
> 
> [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.
> 
> 
> [Problem]
> 
> Only the plugin itself "knows" what to do when it is to be bypassed.
> 
> 
> [Proposed Solution]
> 
> Therefore I propose to introduce a means to handle the situation:
> 
> 1) a port-property intended for marking a lv2:toggled input port:
> http://lv2plug.in/ns/ext/port-props#bypass
> 
> 2) a host-provided feature (lv2:requiredFeature, lv2:optionalFeature):
> http://lv2plug.in/ns/lv2core#bypassFeature
> 
> 
> (1) a host should not display this port but rather use it instead of the
> host-provided bypass toggle mechanism/button.
> 
> 
> (2) It allows to plugin to handle cases depending on host support. It
> also provides "pro" plugins with a means to refuse to load in a host
> that does not support (1).

This sounds reasonable to me.  I had figured that designations mean the
host could at least correctly bypass, but this is a much better idea for
the reasons mentioned.  Also backwards compatible in that the port would
still just work as expected if a user is twiddling bypass in an
oblivious host.

Not sample accurate, but such is control ports.  We can use the same
designation/property with a hypothetical future event-based control
system though.

> A host supporting 'bypassFeature' must always add any plugin which does
> have a port tagged 'bypass' in bypassed mode and un-bypass it after the
> first process callback. That will allow for clickless insertion of the
> plugin. (same for removal, first bypass, then remove.)

One might argue that this is distinct functionality?  The idea is good,
but maybe it should be a separate feature to allow hosts to support
proper bypass without the clickless insertion, which is a bit of
additional complexity?

-- 
dr