Open Bremmers opened 9 months ago
Hi, I'm not familiar with the MIDI info, is it part of MIDI 2.0? Given that we have raw MIDI 2.0 already do we need this? Isn't this already part of the MIDI 2.0 protocol?
"MIDI info" is just the name of the extension. A host needs this info from the plugin if if wants to support parts of Property Exchange which is part of MIDI-CI (CI = Capability Inquiry). MIDI-CI is part of MIDI 2.0, but it can also be implemented by MIDI 1.0 devices. It's built on sysex messages.
One of the Property Exchange resources is 'ChCtrlList', which is a JSON array describing all MIDI controls the receiver responds to. Here's a super-short one, as an example:
[ { "title": "Volume", "ctrlType": "cc", "ctrlIndex": [7], }, { "title": "Modulation Wheel", "ctrlType": "cc", "ctrlIndex": [1], }, ]
A sender (keyboard) receives this info from a receiver (DAW, synth etc.), so it can configure itself to work with the receiver. That's the thing MIDI-CI brings to the table: the sender knows things about the receiver, which is something new for both MIDI and CLAP.
So the benefit of using this extension versus sysex is that you can query it on the main thread?
Here's the thing I don't quite understand @Bremmers (and it really is ignorance not challenge)
midi2-property-exchange.h
and associated. And perhaps have a midi2-protocol-exchange.h
extension parallel (or perhaps a midi2-ci.h
which contains both@baconpaul
The other 'big thing' besides Property Exchange is Profiles. Protocol negotiation was moved from MIDI-CI to the UMP protocol, I suggest you just ignore that bit.
MIDI-CI is bidirectional. A MIDI-CI enabled piano keyboard which sticks to the old MIDI 1.0 standard would have two DIN cables, the second one is for received data from the DAW or synth it's connected to. But it's still just a piano keyboard that doesn't include sounds. In fact, such a device seems to be coming soon: https://www.gearnews.com/leak-korg-keystage-midi-2-0-controller-with-polyat/
There was a PR for a profiles extension which I accidentally deleted two days ago
IIRC we explicitly didn't do things like this because it can lead to problems if a plugin supports a certain feature but fails to advertise it correctly, or vice versa. But hosts need to know...
So the benefit of using this extension versus sysex is that you can query it on the main thread?
It also defines a way to get information out of a note input port. The information is going in opposite direction.
there's the wrapper code.
your comment #3 - "having to read the manual to decide mid cc whatever is whatever" - makes me think this really is tightly coupled with the midi param mapping somehow.
there's the wrapper code.
Hmm, I actually did find that file by myself, but stopped reading two lines before the good bit started. Pfff...
Looks good to me. If it ends up being a standalone extension it would need a host interface with a 'changed' method I think.
your comment #3 - "having to read the manual to decide mid cc whatever is whatever" - makes me think this really is tightly coupled with the midi param mapping somehow.
I see your point. I wonder why exactly we do have https://github.com/free-audio/clap/blob/main/include/clap/ext/draft/midi-mappings.h in the first place. @abique ?
Yeah my view, and again remember it is a woefully uninformed one so I'm being careful to admit that, is that we probably want extensions which
again: woefully under informed. I have never touched a midi 2 device.
I see your point. I wonder why exactly we do have https://github.com/free-audio/clap/blob/main/include/clap/ext/draft/midi-mappings.h in the first place. @abique ?
It is an old thing. I don't see it being useful because it doesn't allow sophisticated mappings. We can probably throw it away.
midi-info extension