update MidiDeviceService to use UMP Endpoints in June 2023 updates about aap-core HOT 2 CLOSED

One thing to consider is that UMP Endpoint Configuration is not going to be "parsing bytes input as MIDI 1.0 bytestream and switch protocol internally" - because (unlike old approach with Set New Protocol) there will not be MIDI1 sysex bytestream inputs. UMP Endpoint Configuration is only sent as UMP, which means the UMP based connection is supposedly already established.

The expected MIDI2 device discovery mechanism is that MIDI-CI Discovery service will generate the list of capable MIDI devices that meets the requirements the CI Discovery Initiator filled. This assumes that the listed devices' ports can already handle UMPs, without protocol promotions (which are deprecated) and thus the protocol configuration is not done at their MIDI messaging level.

There is a super-hacky workaround to make it process UMP Endpoint Configurations over MIDI 1.0 bytestream though - send UMP Stream messages (Fn xx messages) anyways, and detect them at AAPMidiProcessor level (or at Kotlin level), ignoring any possibility that they could be valid SysEx that targets those vendors that overlap IDs(!) It is brutal to them (MOOG etc.) but IIRC there is no conflicting Android app so far, so it would suffice until Google comes up with valid MIDI 2.0 support updates that covers MidiDeviceServices.

from aap-core.

Actually the concerned conflicts ^ was based on the wrong assumption that the packets are sent in Big Endian. On Little Endian Android platforms (which I guess is mostly true for arm64) such a UMP will begin with a sequence of \0 for 12 bytes.

It is now confirmed to work with c737fe6 with compose-audio-controls demo app.

from aap-core.