30 May
2012
30 May
'12
1:25 a.m.
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:
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().
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. 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