I’m looking at the new IMidiMapping2 interface and I have some questions.
IMidiMapping2 allows us to fetch a list of “Midi1” and “Midi2” controller assignments. However, if we look at the Midi2Controller struct, we see that it has a field that denotes the controller as either “registered” or “assignable”. Does that mean that these controllers are effectively only RPN and NRPN controllers (MIDI 2.0 Channel Voice status nibble 0x2 and 0x3 respectively)? It certainly looks this way, based on the note expression synth demo.
If I’ve understood this correctly, then the “Midi1” and “Midi2” naming is confusing, since controllers, RPNs, and NRPNs are concepts in both MIDI 1.0 and MIDI 2.0. It’s misleading to refer to RPNs/NRPNs as “Midi2” and controller-changes as “Midi1”. I guess this can’t be fixed now that the naming is part of the ABI, but some documentation would definitely help.
In the old IMidiMapping interface, a given controller could only be mapped to a single parameter at a time. However, with the new interface, a plugin could reasonably report that the same CC controls multiple parameters on the input, and that a single parameter emits multiple CCs on the output. Is this design deliberate, or would this count as plugin misbehaviour?
thank you for your Feedback.
The struct Midi2Controller refers to MIDI 2 Registered and Assignable Controllers. These UMP MIDI 2 Message Types are specified by the MIDI Association to map and translate directly to MIDI 1 RPN and NRPN. In that regard they are both MIDI 1 and MIDI 2. We understand that this confused you and will consider to add a clarifying comment bringing RPN and NRPN into that context.
Generally we think that Plugins should avoid allowing n-to-m Mappings of Controllers and Parameters as it could lead to inconsistent states in the representation of Controllers and Parameters within the host which could confuse the user. Nevertheless, we think that there may be special situations where such mappings could be intended, eg when layering sounds within a multitimbral Plugin. Therefore we don’t want to disallow such Mappings. We will extend the documentation to comment on n-to-m mappings.
Thanks
Thanks for the reply! That’s helpful to know which behaviours to expect from plugins as a host author.
While you’re looking at documentation, I would also find it helpful if you could take a look at the docs in ivstmidicontrollers.h, from the “Extra” heading onwards. Specifically, it would be useful to know the exact status bytes corresponding to each of these controller numbers, as a few of them are ambiguous. I’m not sure how kCtrlQuarterFrame and kSystemCableSelect should be mapped to MIDI events, since these are not terms that appear in the MIDI spec. Additionally, some messages (kSystemTuneRequest, kSystemMidiClockStart, and others) have no additional data bytes in MIDI 1.0/2.0, but the documentation still says to “use LegacyMIDICCOutEvent.value only” which (presumably) would have no effect.
again: thank you for your Feedback. Good points. We will update the documentation.
kCtrlQuarterFrame refers to MIDI1 System common message 0xF1 “MIDI Time Code Quarter Frame” which is expected to have 1 byte / 7 bits data payload.
kSystemCableSelect refers to MIDI1 System common message 0xF5 which is in fact undefined and not expected to have any data payload. It would be reasonable to ignore such events, due to their undefined meaning.
Additionally, some messages (kSystemTuneRequest, kSystemMidiClockStart, and others) have no additional data bytes in MIDI 1.0/2.0, but the documentation still says to “use LegacyMIDICCOutEvent.value only” which (presumably) would have no effect.
Absolutely correct, the documentation was misleading. All of the following events have no data payload and refer to single byte MIDI1 messages: