linuxaudio.org

--20cf300fae7dd71c9304c12d1573

Content-Type: text/plain; charset=ISO-8859-1
On Tue, May 29, 2012 at 9:37 AM, Albert Graef  wrote:
> On 05/29/2012 02:23 PM, Paul Davis wrote:

quoted text
> > 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 ...
--20cf300fae7dd71c9304c12d1573

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
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:

quoted text
> there's a misconception right there, i think. you wouldn't dea=

ctivate it

quoted text
> to listen to the dry signal. you'd bypass it using some feature of=

 the

quoted text
> 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&=

#39;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 circu=

mstances should the host/user call deactivate/activate?if the host/=

user has done this, then they should be clear on the consequences. you don&=

#39;t call these functions in order to bypass a plugin. you call them speci=

fically 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% wh=

ether deactivate/activate is either of these ... 
--20cf300fae7dd71c9304c12d1573--