[LAU] LV2 control-ports and midi binding -- was Re: [ANN] setBfree v0.8

Rui Nuno Capela rncbc at rncbc.org
Tue Jun 23 11:24:35 UTC 2015


On 2015-06-23 01:21, Robin Gareus wrote:
> 
>> otoh. what i've been saying is about plugins telling the host that 
>> "this
>> particular thing of mine has changed and you, the host, must do
>> something about it" !
> 
> It works both ways.
> 
> LV2 Midi output is one example where many hosts already parse LV2 Atoms
> generated by a plugin and take action accordingly.
> 
> It also works for float or ints and vectors, but there is currently no
> plugin that uses it that way. Currently the only notifications that 
> some
> hosts (Ingen, jalv and Ardour, soon also Carla) intercept is filenames
> (eg plugin restores state and notifies host about changed file).
> 

i guess i've been saying that it *should* be something similar to the 
port_event() and write_function() methods which are for the plugin <-> 
UI interface, but then for the plugin <-> host interface, which there 
isn't  but shared-mem (de)referencing.

yes, there's also the lv2atom::eventTransfer mechanism, but this time 
it's a host <-> UI interface; again, "we" need something similar for the 
plugin <-> host interface, especially to let the host acknowledges that 
the plugin changed or wants to change one of its own parameters.

look, for instance, there are a world of plugin instruments out there 
that supplies its own presets, addressable through MIDI 
bank_select+program_change, which are channel messages, so it should 
only affect one of the plugin parts (if multi-timbral) and NOT the 
entire and complete plugin instance state. in response to this kind of 
MIDI input the plugin should or even must change one or more of its own 
parameters besides other internal state specific to the part being 
selected.

note that all of this often occurs *without* UI intervention (or 
proxying) as the UI might well be not visible at all. now, if the host 
doesn't get it properly notified it will assume the previous or even 
(re)set to its own version of the parameter values, with unpredictable 
consequences and most probably NOT what the incoming MIDI PC message 
meant in the first place (changing an instrument part preset or 
program).

of course this also applies to a plugin's own MIDI CC configuration, 
binding or assignment. again, there's a vast multitude of plugins which 
have it as on their own business, that is, it's not necessarily a host's 
provided feature; a plugin's MIDI CC real-time response most probably 
goes to one or more of its own parameters, so they will change them as 
sees fit and to its own purpose--the host *must* know or listen that 
this event is occurring and react accordingly.

alas, in LV2 there's no standard defined way to do just that. iow. LV2 
dictates that all plugins must not ever alter their own parameters 
(input control ports) and thus delegate all MIDI CC, PC and any other 
controllability features and support into host's shoulders.

and that's a shame if it stays this way.

cheers
-- 
rncbc aka. Rui Nuno Capela



More information about the Linux-audio-user mailing list