On 06/22/2015 08:01 PM, Albert Graef wrote: > On Sun, Jun 21, 2015 at 10:31 PM, Robin Gareus <robin@xxxxxxxxxx> wrote: > >>> 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. >> > > 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? > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
