[LV2] [LAU] LV2 control-ports and midi binding -- was Re: [ANN] setBfree v0.8
robin at gareus.org
Tue Jun 23 06:37:19 PDT 2015
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
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
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
> 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.
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."
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.
More information about the Devel