iOS 14.2 MIDI connections broken

The JUCE toolset has to be updated to be compatible with the new Apple API for MIDI2.0 / MIDI1.x
Use of the old calls leads to crashes in iOS 14.2 beta.
Can someone confirm this is in the pipeline?

Bumping this.
Can someone from the core dev group tell anything about this?

Yes, we’ll be adding support for the new API in the near future.

The new API is only available on iOS 14+, so apps wishing to support older iOS versions must continue to use the old API. Hopefully any regressions in the old API will be resolved by Apple before 14.2 leaves beta.

That being said, I wasn’t able to reproduce these crashes in the iOS 14.2 Simulator. I tried adding some virtual ins and outs to JUCE’s MidiDemo app and routing MIDI through them, and this seemed to work fine. Please could you provide more details about the crash you’re seeing, so that we can attempt to reproduce it ourselves?

It crash reliably on a real device (iphone 11 and ipads pros tested) running 14.2, whenever sending a MIDI note on a created virtual channel in the current juce head. The crash happens at MIDISend and MIDIReceived which were depricated.

does the used Xcode SDK version influence the results?

Now that 14.2 is officially available, is there any fix for this?

Are you seeing issues with the actual 14.2 release (i.e. not the beta)? If so, please can you provide some more details of the issue (ideally with a minimal code sample) so that I can attempt to repro?

I just tried updating the MidiDemo to create a virtual input and output in the constructor. I’m able to run this modified demo on a physical device running iOS 14.2. When I touch the keyboard while my new virtual output is selected, I can see midi messages being received. I tested with the iOS deployment target set to 14.2 and 12.0. I’m using the Xcode 12.2 RC on Catalina 15.7.

Sorry for the delay, I’ve been trying to get a consistent repro, but I’m afraid I haven’t succeeded yet. The issue happens more frequently in our app, but I got the MidiDemo to reproduce it a few times now by sending lots and lots of note-ons by tapping the keyboard rapidly.

Since updating to the official iOS 14.2 release (using an iPad 8, OSX 10.15.7 and xcode 12.1, but having downloaded the 14.2 sdk with xcode 12.2 beta), we are seeing two issues and are assuming they are different manifestations of the same underlying problem.

The first is a crash when JUCE calls MIDISend (an CoreMIDI call):

and the second is a series of 3 errors output to the debug log when JUCE calls MIDIObjectGetString/IntegerProperty(), when attempting to get properties about the device in either MidiInput::getAvailableDevices() or MidiOutput::getAvailableDevices():

Here are the printed error messages:

CoreMIDI error: 56 - ffffffce
CoreMIDI error: 62 - ffffffce
CoreMIDI error: 70 - ffffffce

Using (and this forum post: How to translate CoreMIDI error numbers?) we’ve found that ffffffce corresponds to a kAudio_ParamError from CoreAudio.

Both issues happen after we have connected to a physical midi BT device and have been communicating with it – although it can happen almost immediately or after a few minutes.

We assume the first issue (MIDISend()) happens if the error occurs while we are already on the path to send midi, and the second (getAvailableDevices()) when our code detects the device has gone away, so stops sending midi, but continues to poll the device list.

Although anecdotal, a quick googling of “ios 14.2 midi issue” does reveal a few products are also facing this issue:

I wanted to add that I just tried reverting to iOS 14.1, and with the exact same code, both issues go away.

Thanks for the detailed report. I’m still investigating this issue and have a consistent repro now, but haven’t yet managed to find a robust fix/workaround. As I mentioned earlier, switching to the new API isn’t really viable at the moment as it would prevent users from targeting iOS versions earlier than iOS 14, so I’m trying to find a safe way of using the old API. I’ll update this thread once I’ve made some more progress.


I’ve now managed to repro this issue in a plain Swift app with no JUCE whatsoever, so I’ve submitted a bug report to Apple.


reuk, did get any update from Apple on this? Sorry to jump in but I’m an iOS developer directly using CoreMIDI and having crashes related to MIDISend on iOS 14.2. Just trying to find anyone out there who has made progress with this and might be able to lend some insight. Thanks.

This seems to be fixed in ios14.3, but there isn’t a known a release date. :frowning:

Well, that’s a silver lining at least!

1 Like

I’ve just pushed an update which should allow devices running iOS 14+ to use the newer CoreMIDI API if it is available. Devices using an older version of iOS will gracefully fall back to using the old API.

Sorry for the delay in replying. I haven’t heard anything, no, although the issue is apparently fixed in 14.3. To support 14.2 as well as older versions of iOS with a single binary, it’s necessary to use @available checks to query the currently-available API, and to use the newer functions if they are available.

Amazing thanks, will test!

Wow, you just whipped up a full MIDI 1 to UMP conversion library?!? I will definitely be taking a look at this. :slight_smile: Nice work!

Why are the UMP classes in the juce_audio_devices module?
Shouldn’t they live in juce_audio_basics module along side the midi and mpe classes?

The UMP classes are still in progress - they work well enough to handle Bytestream MIDI -> Universal MIDI Packet conversion for the CoreMIDI API, but the interfaces haven’t been set in stone yet. In particular, we’d like to see how the OS-level interfaces on other platforms (Windows, Android) are updated to handle UMP-formatted MIDI before committing to the UMP API in JUCE.

At the moment, we only need the UMP classes to implement the CoreMIDI wrapper in juce_audio_devices, so we’ve added the classes as an implementation detail to that module. When we’re ready to make the UMP APIs public, we’ll move that code into the juce_audio_basics module and make it public.