29 May
2012
29 May
'12
4:41 p.m.
On 2012-05-29 14:37, Albert Graef wrote:
On 05/29/2012 02:23 PM, Paul Davis wrote:
aha. qtractor doesn't have this "bypass" option as Paul refers to (i
guess from ardour's;) as being independent of lv2
deactivate()/activate() calls...
fact is, qtractor does call lv2plug.in->activate()/deactivate()
respectively, whenever its own plugin "activate"/"deactivate" commands
are issued, or the equivalent for other plugin types (vst, ladspa, dssi.
altough neither of which resets qtractor's external midi controllers
assignments per se...
however, depending on plugins implementation, it might (yeah might)
reset a plugins internal state re. their eventual midi control state,
leaving the host, qtractor in particular, to play catch-up after every
deactivate/activate() cycle...
yeah. you might have a point in there ;) maybe it's all qtractor fault,
of not having a separate "bypass" switch independent of plugins
(de)activate/activate() sort of power-cycle...
hmm... thinking of it, my recent "vee one" proto-toys (synthv1 &
samplv1) actually rest their midi control state upon lv2::(de)activate()
... that is, they behave as if a "panic" button has been issued
especially the all-controllers-off one (ie. GM CC#121) ...
so, should i read this whole question about a case of lv2 plugin
implementation or is that a lack of simple "bypass" on qtractor (or any
other lv2 host) to be at stake ?
cheers
--
rncbc aka. Rui Nuno Capela
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.