[LV2] plugin bypass

[David Robillard]

On Thu, 2014-05-08 at 15:09 +0000, Fons Adriaensen wrote:
> On Wed, May 07, 2014 at 04:07:08PM +0200, Robin Gareus wrote:
> 
> > I cannot think of a good use-case that would require un/bypassing a
> > plugin with sample accuracy multiple times per process cycle.
> 
> Or even controlling it in general.
> 
> The algorithms used in most of my plugins (those for AMS excepted)
> and in the zita series of processors will only look at control port
> values at regural intervals determined internally, and those intervals
> tend to be much longer than typical jack periods. Any attempt to control 
> them 'faster' will simply be ignored. This is part of their design, and
> therefore one of the things I don't want to be modified if they are
> ported to any plugin format. It's in fact one of the reasons why I tend
> to discourage such ports.

By default LV2 is the same as LADSPA in this respect, i.e. no guarantees
at all, so you can't really do constant interval sampling of controls.

You can specify the min/max and/or "fixed" and/or "power of two" for the
block size with the features in http://lv2plug.in/ns/ext/buf-size/
though host support is still a bit lacking (though the simple ones
usually get it for free on jack1).

The nice thing about events/ramps is that the plugin can "sample" at
regular intervals without restricting the run block size.  That does
mean the plugin has to cut processing at event boundaries itself if it
wants the sample accuracy, but wouldn't be required to do so.  I am
convinced that control ports are an unbelievably crap idea, but events
really need to be thought out first...

-- 
dr