21 Jun
2015
21 Jun
'15
8:07 p.m.
On 21-06-2015 19:03, Robin Gareus wrote:
On 06/21/2015 06:14 PM, Christopher Arndt wrote:
LV2 can report the initial/wanted CC value.
If your control port has something like this:
[
a lv2:ControlPort, lv2:InputPort ;
lv2:index 2;
# etc
midi:binding [
a midi:Controller ;
midi:controllerNumber 1
] ;
] .
I guess in LV2 presets the mapping could be described in the same way,
example:
[
lv2:symbol "attack" ;
pset:value 0.5933333 ;
midi:binding [
a midi:Controller ;
midi:controllerNumber 11
] ;
],
With the initial midi mapping included in the plugin ttl the hosts will
know what to do.
Carla implement this (and also an old lv2 spec for the same thing).
No idea about other hosts.
see http://lv2plug.in/ns/ext/midi/#binding for more details.
I'm not sure I understand or agree with the
reasoning behind this. The
advantage of using an LV2 plug-in is having a unified interface to set
plug-in parameters and save their state. Mapping MIDI to plug-in
parameters should ideally be the job of the LV2 host.
Correct. For that to work
the host needs to know which parameters can be
automated and the current binding. This information needs to be
host-independent (part of the plugin state), so that it can be re-used
in various hosts across platforms.
Currently LV2 does not officially support saving parameter control bindings. This is work in progress on the LV2 front, and
co-incidentally being
pioneered by setBfree, which can already dynamically export its
control-map and bindings.
LV2 already has a vocabulary in place (http://lv2plug.in/ns/ext/patch/)
but there are no semantics that govern bindings, yet.
With recent liblilv-SVN and Ardour4-git you can already achieve this (by
copying the midnam out-of-band). Note however that this is still very
much work-in-progress.
tbh I think you're doing it wrong.
You want to automate some plugin parameters, that's fine, but that
should be done on the host-side!
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.
If a midi-cc event on the plugin side triggers some control port update,
the host cannot know about it.
Carla already includes the midi-cc configuration as part of a saved preset,
and when that preset is loaded it will restore the cc mapping.
(it does not export presets to lv2 format yet though)
Carla will not load the midi:binding [] inside a lv2 preset right now,
because this is actually the first time I though about it...
Anyway, is there a real reason for setBfree to not have its parameters
exposed as control ports?
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.