[LAD] Should LV2 Activate() clear MIDI CC parameters?
rncbc at rncbc.org
Tue May 29 13:41:39 UTC 2012
On 2012-05-29 14:37, Albert Graef 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
> Yes, of course this depends on the host. But presumably an LV2 host
> would then also deactivate the plugin and later reactivate it to
> it to a sane state? At least that's what I thought these callbacks
> for. IIRC that's how it works in Qtractor (Rui, please correct me if
> wrong), and that certainly makes sense to me. I didn't test this with
> Ardour, though.
aha. qtractor doesn't have this "bypass" option as Paul refers to (i
guess from ardour's;) as being independent of lv2
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
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 ?
rncbc aka. Rui Nuno Capela
More information about the Linux-audio-dev