search

atsushieno / aap-core

an Audio Plugin Format/Framework for Android
MIT License
91 stars 3 forks source link

update MidiDeviceService to use UMP Endpoints in June 2023 updates #161

Closed atsushieno closed 1 year ago

atsushieno commented 1 year ago

I have been trying to make changes to compose-audio-controls sample app to work more like a generic MIDI 2.0 controller. It should use the latest UMP Endpoint configuration mechanism to change what to send over the transport.

That is one matter at the compose-audio-controls sample app, but we should update AAPMidiProcessor to support the new UMP Endpoint mechanism as well. Set New Protocol has been already disabled right now (as I was kind of waiting for the Android API updates, which did not happen at 14), so it is good time to rework on it to make it MIDI2 ready.

Once it is done, we would be able to build some generic MIDI2 keyboard app. Then we could optionally remove the keyboard part from our native compact default view, but that is an optional idea (maybe it is still useful).

atsushieno commented 1 year ago

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.

atsushieno commented 1 year ago

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.