MIDI-CI integration

[atsushieno]

ktmidi 0.7.0 features full-scratch MIDI-CI implementation which would improve AAP interoperability through Profile Configuration, Property Exchange and Process Inquiry. They are NOT for realtime processing, but helps some non-RT information exchange.

We would come up with some draft specification, maybe custom Profiles, and predefined Property resources.

[atsushieno]

ktmidi 0.8.0-pre3 comes with workable MIDI-CI support in the library API (which was not the case until that version and was useful only as ktmidi-ci-tool) so we can actually start designing this feature (not necessarily meant that I will start it now).

[atsushieno]

At which level should we support MIDI-CI?

It is not likely at the plugin API level; the plugin API is intended for use in binaries. MIDI-CI messages could be interchanged through the MIDI ports. When a plugin supports ProgramList and/or those controllers, they could be queries through the MIDI ports.

What should implement this? Not likely by each plugin developer. AAP should provide some utility stuff to plugin developers (or wrapper developers). Ideally, the plugin hosting SDK (androidaudioplugin.aar, androidaudioplugin-midi-device-service, aap-lv2 or aap-juce) should support automatic MIDI-CI messaging.