free-audio
MIDI-CI profiles extension
Hi @Bremmers,
Thank you very much for this PR.
Even if the plugin supports this extension, it should still be able to do the MIDI-CI handshake using raw sysex right?
I'm thinking of it because one scenario is a mini host that is just passing midi and audio input to a plugin, and routing its outputs. Think of a hardware pedal effect hosting clap plugins.
So in that case the plugin would have to support sysex based handshake in the process() callback.
Then if the plugin supports this extension, it has to support an additional way of communicating the MIDI-CI info. Having two ways to do the same thing is not desirable in my opinion because it leads to dirty workaround when the plugin has a bug in a specific way but not in another, ...
What I wish for is to have a single way of exchanging the MIDI-CI info.
If this is done via sysex, and we add a new callback plugin->flush_events() similar to how we flush params when the plugin isn't processing, then the plugin can easily factorize the code for dealing with the MIDI-CI from the process() callback and from plugin->flush_events().
Does it sound right?
Even if the plugin supports this extension, it should still be able to do the MIDI-CI handshake using raw sysex right?
No, the idea is to use the extension exclusively.
Even if the plugin supports this extension, it should still be able to do the MIDI-CI handshake using raw sysex right?
No, the idea is to use the extension exclusively.
So, it means that a simple host that simply forwards all the midi in/out to a plugin without any intelligence will result in the impossibility to use MIDI-CI?
@Bremmers - remember I know nothing about CI
In UMP getting the packet was key. The host getting in the way would have been a bummer.
Why is CI different?
Also: I do worry a bit about "we can write a better protocol than the MMA" - that was one of the things people disliked about MIDI 1 in VST3.
Even if the plugin supports this extension, it should still be able to do the MIDI-CI handshake using raw sysex right?
No, the idea is to use the extension exclusively.
I think this is not applicable.
One can't expect all hosts to transform MIDI-CI sysex into high level calls for the plugin. Imagine a host that was written 2 years ago, this one will never be able to do the job, while it can forward MIDI 2 sysex.
And for the plugin it is an even worse situation, let's say the host does a poor job at converting the MIDI 2 sysex into CI calls, there's nothing the plugin can do. While on the other hand, if the plugin handles MIDI CI sysex directly it has full control, and is more likely to behave the same from one host to another.