On Tue, May 29, 2012 at 9:37 AM, Albert Graef <[email protected]> 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 ...
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
