Hi,
On iOS 27, Network MIDI (Session 1) no longer shows up in MidiInput::getAvailableDevices().
We enable MIDINetworkSession in the app. CoreMIDI still lists Session 1 (MIDIGetNumberOfSources), but JUCE 8.0.14 does not. It worked with JUCE 8.0.10.
The session is running, it’s just missing from the JUCE list.
Please let me know if there’s anything else I can provide to help.
Thanks
Samuele
I’m seeing that the old MidiInput/MidiOutput interfaces don’t pick up the network session, but the new ump::Input and ump::Output interfaces do make it available. The network session shows up in the UmpDemo, but not in the MidiDemo.
A bit of background might be helpful:
Apple platform APIs use UMP to send and receive messages for all devices, regardless of the capabilities of the underlying transport. For a UMP connection, the system allows connecting to the “endpoint” that spans all 16 groups, but it also allows connecting directly to individual function blocks on the endpoint. In the past, JUCE’s MidiInput and MidiOutput also exposed these “aliased” connection points as discrete inputs and outputs.
When JUCE introduced the new UMP APIs, it still needed the old MidiInput and MidiOutput APIs to behave in the same way as before. Specifically, unique identifiers needed to remain unchanged, so that new versions of programs could reopen devices using saved unique identifiers.
The MidiInput and MidiOutput types are now implemented in terms of the more general ump::Input and ump::Output types on all platforms. However, a single ump::Input or Output might represent up to 16 legacy bytestreams, each of which may have its own system-provided unique ID. JUCE’s UMP API attempts to map endpoint IDs, so that users can determine how groups on UMP endpoints correspond to legacy MidiInputs/MidiOutputs.
The CoreMIDI API doesn’t make it easy to relate ‘aliased’ connection points on an endpoint to the endpoint that contains them, so JUCE uses some heuristics to try to determine which connections are aliased. In short, we look for a connection point that’s capable of transmitting ‘groupless’ messages, and assume that this is the full UMP connection point. This connection point will not be exposed through the old MidiInput/MidiOutput API. If the same device also contains connection points that can’t transmit groupless, we assume those are aliased connections, and expose those through the old JUCE APIs.
Things get a bit weird in the network MIDI case. A standard network MIDI connection can send only bytestream MIDI, the protocol cannot be used for UMP (as far as I can tell). However, the OS reports that the network MIDI sessions are capable of transmitting groupless, and have an active group bitmap indicating that the first four groups are all active. This means that JUCE’s heuristics pick up the connection point as a ‘full UMP’ connection point, and so it doesn’t get exposed through the old MidiInput/MidiOutput APIs.
If I connect my mac to the iOS simulator’s network session, then I can send messages between two copies of the UmpDemo. It appears as though messages sent from any group, even groups outside the active group bitmap, are received as group 0, so the active group bitmap appears to be inaccurate. I also can’t get groupless messages to be received, which is consistent with a connection that can’t transmit in UMP format.
My impression at the moment is that the OS behaviour is buggy. The properties of the network driver seem to be incorrect for a connection that can only transmit bytestream messages.
Hi Reuk,
Thanks for the detailed explanation.
Do you think there’s a workaround or a temporary patch I could apply in JUCE to keep using the MidiInput API until this is resolved?
Thanks again,
Samuele
