<br><br><div class="gmail_quote">On Tue, May 29, 2012 at 9:37 AM, Albert Graef <span dir="ltr"><<a href="mailto:Dr.Graef@t-online.de" target="_blank">Dr.Graef@t-online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On 05/29/2012 02:23 PM, Paul Davis wrote:<br>
> there's a misconception right there, i think. you wouldn't deactivate it<br>
> to listen to the dry signal. you'd bypass it using some feature of the<br>
> host.<br>
<br>
</div>Yes, of course this depends on the host. But presumably an LV2 host<br>
would then also deactivate the plugin and later reactivate it to reset<br>
it to a sane state? At least that's what I thought these callbacks were<br>
for. IIRC that's how it works in Qtractor (Rui, please correct me if I'm<br>
wrong), and that certainly makes sense to me. I didn't test this with<br>
Ardour, though.<br>
<br>
Otherwise, how is an LV2 plugin supposed to know that it has been<br>
suspended and should prepare its internal state to be switched back on<br>
again? All the host knows about the plugin are its ports, so it's<br>
limited in what it can do. Only the plugin itself knows about the extra<br>
cleanup it might want to do when being switched off and then back on<br>
again, no?<br></blockquote><div><br>the question really is under what circumstances should the host/user call deactivate/activate?<br><br>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.<br>
<br>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 ... <br>
</div></div>