On Tue, May 29, 2012 at 9:37 AM, Albert Graef
<Dr.Graef@t-online.de> wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
> 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?
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 ...