-
Notifications
You must be signed in to change notification settings - Fork 118
MIDI-CI profiles extension #363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: next
Are you sure you want to change the base?
Conversation
now works per-port, supports single channel, multi channel, group and port profiles, activate/deactivate renamed to enable/disable
now works per-port, supports single channel, multi channel, group and port profiles, activate/deactivate renamed to enable/disable
…) to get_details()
de3907e to
c279d5a
Compare
16765e6 to
b16e5f4
Compare
eff5302 to
00113aa
Compare
fb5acc0 to
89b761c
Compare
|
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 Does it sound 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. |
I think this is not applicable. One can't expect all hosts to transform MIDI-CI sysex into high level calls for the plugin. 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. |
65f58e0 to
3e2c1a5
Compare
This is an updated version of the PR I accidentally removed a month ago.