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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux