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

From: Robin Gareus <robin@email-addr-hidden>
Date: Tue Jun 23 2015 - 16:37:19 EEST

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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jun 23 20:15:02 2015

This archive was generated by hypermail 2.1.8 : Tue Jun 23 2015 - 20:15:02 EEST