22 Jun
2015
22 Jun
'15
9:20 p.m.
On 06/22/2015 08:01 PM, Albert Graef wrote:
On Sun, Jun 21, 2015 at 10:31 PM, Robin Gareus
<robin(a)gareus.org> wrote:
I must confess that I'm guilty of that, too -- my faust-lv2 and faust-vst
plugin architectures for the Faust programming language all do their own
midi cc processing (according to the corresponding hints in the Faust
program), even though in this case all the control values are also exposed
as control ports (and the two work in concert, of course).
How do you deal with conflicting information in this case?
What happens if a MIDI-CC sets a parmeter to a different value as is
currently given on the corresponding control input?
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.
In principle most of this could (and should) all be
done on the host side
(although there might be special circumstances under which some processing
needs to be done on the plugin side). But right now you can't even be sure
what facilities the host offers for that purpose. Does it support the
midname spec? Does it take corresponding hints from the LV2 manifest? Or
will it simply pass on midi cc's if there are midi input/output ports? Etc.
As long as the synth takes plain raw midi input there's no way a host
can make the decision.
There is currently no spec in the LV2 world that allows to describe
which raw MIDI-events a plugin [currently] understands and which are
left to the host.
midnam can describe what [internal] bindings a plugin uses and a host
could use this information. Midman is a potential solution, but it's an
offical midi spec, not LV2. The LV2:midi vocab might already be suitable
to also represent this information. I don't know.
In Ardour for prototyping we currently use midnam. Since Midi-CCs are
standard Automatable Control Params in Ardour, they can be bound to
control-surfaces. That part already works but currently requires
installing the midnam manually.
I think that was David's intention all along: MIDI-CC on the host-side
are just control-params (equivalent to control-ports). Midi-Programs are
passed to the plugin as-is. I hope he'll chime in on this.
One way forward is to completely abstract MIDI into [LV2] Events. That
will allows hosts to freely [re-]map CC, or bind CC and PGM to
LV2:Patch/Properties. LV2 already has the vocab for that, but that is a
major endeavor.
Realistically we'll probably be stuck with MIDI for another 30 years..
So we just need to make the host aware which CCs a plugin understands
and the "human readable control" that is currently mapped to that
binding. Using Midnam for this is not elegant, but it's at least
suitable for prototyping and learning lessons.
I admit that I'm confused by the state of affairs
in this department, and
I'm probably not the only one. Sounds like a great topic for discussion at
next years' LAC. :)
+1
2c,
robin