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 https://osstatus.com/ (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.
4 Likes
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.
5 Likes
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. 
Well, thatās a silver lining at least!
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. 
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.