Re: [LAD] Should LV2 Activate() clear MIDI CC parameters?

On Tue, 2012-05-29 at 16:18 +0000, Fons Adriaensen wrote:
> On Tue, May 29, 2012 at 09:48:10AM -0400, Paul Davis wrote:
>
> > the question really is under what circumstances should the host/user call
> > deactivate/activate?
> >
> > if the host/user has done this, then they should be clear on the
> > consequences. you don't call these functions in order to bypass a plugin.
> > you call them specifically when there is a need to completely reset the
> > state of the plugin.
>
> I've always lookat at activate() as part of the sequence
> required to load a plugin and make it work, not as something
> ever explicitly done by the user. If a plugin needs a 'Reset'
> (some do, it depends on the particular effect), it should have
> a Reset button.
>
> Since in LV2 activate() and deactivate() do not affect port
> connections, I'd say they should not reset any controller
> values that the plugin gets from MIDI input. The controller
> remains connected, but it doesn't know it should resend its
> current value if the plugin would reset it.

This is a digression, but I think port_connect() is the dumbest thing in
LV2. I have all sorts of plugins that would be stateless but for the
idiotic need to keep that stuff around, when they are only used in run
anyway. All that function calling is also expensive, most hosts I have
seen just end up connecting every port every cycle anyway. It's absurd.

Should be arrays of buffer pointers to run().

> AFAICS, Ardour's 'activate' and 'deactivate' (at least for
> LADSPA plugins) do not call those functions, they just change
> the signal routing. Which looks to me as the right thing.

It's the rightest thing, but it also wastes cycles.

> Another questions if a host bypasses a plugin, should it still
> provide input signals to the plugin and run its process() ?

For live plugins it is strictly required to, for non-live plugins it is
not.

Since we don't actually have stateless plugins at all (thanks to the
above connect_port mistake) activate and deactivate are essentially
'start time' and 'stop time'. Whenever the time of data processed by
subsequent calls to run() is not contiguous (e.g. a transport locate)
the plugin MUST be deactivated and reactivated again.

In other words, if you havn't been deactivated, the audio you are
receiving in subsequent run calls is a continuous stream of audio.
Otherwise you'll end up applying 'trends' (like parameter interpolation)
from the 'previous' (but not) block to the current one, which is wrong.
This guarantee is necessary to be able to do basic stuff like filters
correctly. I think it is the actual motivation for the 'activate resets
state' language (e.g. you must reset your filter state because there's
been a gap in audio), but this should probably be clarified. Nothing in
the spec lays out this 'continuous stream' thing clearly.

tl;dr: The state that needs to be reset is state that depends on a
continuous stream of audio. Midi controllers and such do not cause
problems if they persist across audio gaps, and are not what was being
referred to here.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed May 30 04:15:02 2012