On Tue, 2012-05-29 at 16:18 +0000, Fons Adriaensen wrote:
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
It's the rightest thing, but it also wastes cycles.
> Another questions if a host bypasses a plugin, should it still
For live plugins it is strictly required to, for non-live plugins it is
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.
Linux-audio-dev mailing list