[LV2] plugin bypass

[Robin Gareus]

On 05/07/2014 02:58 PM, David Robillard wrote:
>> > [Problem]
>> > 
>> > Only the plugin itself "knows" what to do when it is to be bypassed.
>> > 
>> > 
>> > [Proposed Solution]
>> > 
>> > 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. 

I cannot think of a good use-case that would require un/bypassing a
plugin with sample accuracy multiple times per process cycle.

> We can use the same designation/property with a hypothetical 
> future event-based control system though.

Right. Though this will make things rather complex on the plugin side.

e.g. The simple-amp example could just internally ramp the gain to 0 in
one process cycle. Easy. But doing this multiple times in a cycle with
sample-accuracy can make things quite complicated.

I don't know any plugin-host that can automate bypass with
sample-accuracy either and I think we should even discourage that. If
sample-accuracy is required for operating a given plugin properly. Using
"bypass" to do that is the wrong way to begin with.



>> > 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?

Indeed. It is related but keeping clickless-bypass and
clickless-insertion separate features can make sense. The reason to mix
them is mostly political: motivate host-authors to do both.

Semantically a 3rd URI  e.g.
  http://lv2plug.in/ns/lv2core#clicklessInsert
could indicate host support. While (2) would only indicated clickless
bypass.

I'm up for suggestions of good URI names and the proper namespace to put
them. After the dust settled on this discussion, I volunteer to write
doc and an example.

best,
robin