29 May
2012
29 May
'12
3:48 p.m.
On Tue, May 29, 2012 at 9:37 AM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
On 05/29/2012 02:23 PM, 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.
however, david's point stands which is that you really want both (a) a
method to stop and restart the plugin (b) a method to reset to it back to
the state it would have immediately after instantiation. its not 100%
whether deactivate/activate is either of these ...
there's a misconception right there, i think.
you wouldn't deactivate it
to listen to the dry signal. you'd bypass it using some feature of the
host.
Yes, of course this depends on the host. But presumably an LV2 host
would then also deactivate the plugin and later reactivate it to reset
it to a sane state? At least that's what I thought these callbacks were
for. IIRC that's how it works in Qtractor (Rui, please correct me if I'm
wrong), and that certainly makes sense to me. I didn't test this with
Ardour, though.
Otherwise, how is an LV2 plugin supposed to know that it has been
suspended and should prepare its internal state to be switched back on
again? All the host knows about the plugin are its ports, so it's
limited in what it can do. Only the plugin itself knows about the extra
cleanup it might want to do when being switched off and then back on
again, no?