On 06/21/2015 08:07 PM, Filipe Coelho wrote:
[..]
Because you do this inside the plugin and LV2 says you
can't change your
plugin input ports,
it means you can't export those parameters as control ports.
This is indeed the main reason why they can't and won't be exported as
control ports.
If a midi-cc event on the plugin side triggers some
control port update,
the host cannot know about it.
Why not?
The official midi midnam spec is precisely for that case. There are
various hosts (commercial and otherwise) that support it already.
Carla already includes the midi-cc configuration as
part of a saved preset,
That's Carla specific isn't it?
Carla will not load the midi:binding [] inside a lv2
preset right now,
because this is actually the first time I though about it...
Knowing you it'll only take a day or two now until it does :)
Anyway, is there a real reason for setBfree to not
have its parameters
exposed as control ports?
There are way to many of them for it to reasonably work. Particularly in
Carla which sends port_events for all ports in every cycle regardless if
the value has changed. This does not scale.
It also does not allow for midi-feedback. Loading a program (which is
part of a preset) in setBfree sends updates back to the control surface.
eg. load MIDI-program #1 -> drawbars on the organ move to reflect this
change. Likewise for changes using the GUI.
As you already mentioned a plugin cannot modify its own control inputs
and a host cannot reasonably manage [plugin specific] programs (partial
subsets of the whole config). So the way forward is to use meaningful
messages. And currently the only set of specs that satisfies the
requirements for this is MIDI. Sadly LV2 is not there, yet.
If you have an alternative solution for this case, I'm all ears.
If you need to have presets that include midi bindings
you can do like I
posted above.
BUT, again, I believe doing the midi-cc mapping on the plugin side is
the wrong approach.
Agreed, the idea is to eventually delegate mapping it to the host.
ciao,
robin