On 06/23/2015 01:24 PM, Rui Nuno Capela wrote: [..] > yes, there's also the lv2atom::eventTransfer mechanism, but this time > it's a host <-> UI interface; It's for all cases (incl host <-> DSP), except "eventTransfer" delegates it to the host to split an lv2atom:Sequence into individual Events (useful for callback functions and hence indeed common for host -> GUI http://lv2plug.in/ns/ext/atom/#eventTransfer ) If you'd want to use eventTransfer to the DSP, the host needs to split the process cycle at every event-timestamp; hence Sequence of events is a lot more useful. > 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. Yes! I'm with you there 100%. This is a good example where the host simply cannot be in control. The solution I propose for this case is to simply not export the control-parameters as "old-fashioned LADSPA float-pointer inputs" to the host. > 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. yep. > alas, in LV2 there's no standard defined way to do just that. The vocab is there and there are some de-facto examples for patch:set. patch:set param:some_control 1.234f That message can be generated by a plugin (sent to host) and by a host (sent to DSP). but the official doc still says "Other methods, such as setting dynamic parameters via messages, are possible but not defined here." http://lv2plug.in/ns/lv2core/#Parameter So yes, this needs to be worked out. IIUC it's all there already in the LV2:Atom, LV2:Patch and LV2:MIDI doc. But there's no reference implementation for float parameters per se. Current existing examples are filenames and MIDI only. > 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. > I think it's fine if float-pointer input control ports remain completely under the host's control (backwards compat, simple plugins) as long as there are other means that allow a plugin to set its own properties. There's no need to complicate the simple & fast way that's good for 90% of all plugins. Like with AU: If you have a fancy plugin (dependent Params, internal Properties), use the fancy API. 2c, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
