We have found that some virtual MIDI Output ports on iOS are no more selectable.
It most likely happens since JUCE added the support to ID-based MIDI devices:
It is simple to check it with the AudioPluginHost example: in our case Ravenscroft 275 MIDI Output port is not selectable as MIDI Output port from the device manager, using a recent tip of JUCE, but it is selectable using a tip with name-based MIDI devices support.
Indeed, other customers, using our Camelot host, experience the same issue with different virtual MIDI ports created by other Apps.
Can you provide some more details? I’ve tried to reproduce this by creating a new MidiInput device in a JUCE app on iOS and I’m able to select and use this device as a MIDI output in the AudioPluginHost. Does it only occur with MIDI ports created by other apps?
It’s difficult to say exactly and difficult (at least for us) to debug. It happens under some circumstances when selecting MIDI ports created by other Apps. The problem is also that it is not systematically reproducible on any iPad.
Please check this video, as an example. It shows AudioPluginHosts on iPad Pro 2017, iOS 12.4.1, trying to select Ravenscroft275 virtual MIDI port:
I use by purpose AudioPluginHost to exclude any issue in our implementation.
Our software Camelot has the ability to select multiple MIDI outputs at the same time. Another issue has been reported when connecting an external MIDI device that exposes several MIDI ports: when the device is connected the virtual MIDI ports cannot be selected, when the device is disconnected the virtual MIDI ports can be selected (see the attached screenshot).
NOTE: the user did not experience those issues with Camelot build made before ID-based MIDI device support in JUCE.
OK, that’s interesting. It seems like those ports aren’t working because they have been created with a kMIDIPropertyUniqueID which isn’t an integer. Can you change the getMidiObjectInfo() method in juce_mac_CoreMidi.cpp to the following and see if it fixes the issue:
It is still technically an error as the docs state that kMIDIPropertyUniqueID should be an integer so I’d like to keep the CHECK_ERROR macro wrapper around the initial call to MIDIObjectGetIntegerProperty() but fall back to checking for a string property if this fails. Just to confirm, the port is working correctly with this change (albeit with those error messages)?
Yes! The port is working. Now we are preparing a beta-version of our software to be tested by those users that reported the problem… I’m afraid there are several Apps with that issue
Just seen commit aa219c5a0 “Fixed a typo in CoreMIDI that caused it to recognise the wrong the wrong number of input devices” … that explains the other part of my report
I reported that bug and the title is wrong. It was reporting the wrong number of OUTPUT devices. So it may or may not explain the other part of your report…
Yes, the title is wrong. I just mentioned the commit message. In our case, when a multi-output MIDI device was connected, it was impossible to select some other ports.