[LV2] plugin bypass

Robin Gareus robin at gareus.org
Tue May 6 12:50:07 PDT 2014


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).

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.)


Thoughts and comments are very welcome.

Cheers!
robin



More information about the Devel mailing list