In previous iOS versions, if a MIDI device was plugged in, removed and plugged in again, then the unique IDs of its source source and destination endpoints (and also of the device itself and its entities) would persist.
So there would be a msgObjectAdded for a source e.g. "Port 1", UID 123456, then a msgObjectRemoved for the same port, then when plugged in again another msgObjectAdded for "Port 1", UID 123456 i.e. it is the "same" port that was added, removed, and added again. And it would be on the "same" entity, which in turn would be on the "same" device.
Now in iOS 17 the unique IDs do not persist. The second msgObjectAdded will come back with something like "Port 1", UID -438484, on an entity and a device that also have new changed UIDs.
Is this an intentional change? It seems odd that while the device is unplugged I can still find out all about it (name, entities, sources, destinations, all as before except the device is now "offline") yet when it is plugged back in I get brand new versions of all that stuff.
Core MIDI
RSS for tagCommunicate with MIDI (Musical Instrument Digital Interface) devices using Core MIDI.
Posts under Core MIDI tag
8 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Hi there,
We're developing a product which has a BLE module that advertises itself as a BLE MIDI device.
The goal for our iOS app is to have the phone auto-connect to the device, which it already bonded with. Exactly like headphones; Bond one time, and everytime the headphones turn on, the phone automaticly pairs/connects to the headphones.
At the moment, a new connection is required every time the the device turns on and advertises.
I've read on the apple BLE documentation page, that from iOS 16 or later "the system automatically reconnects Bluetooth Low Energy (BLE) MIDI peripherals when powered on, if the device supports pairing. Previously, it was necessary to use Audio MIDI Setup to establish BLE MIDI connections."
( https://developer.apple.com/documentation/coremidi/midi_bluetooth/ )
However, neither our iPhones that run iOS 16+ or macOS 13+ devices re-connect to the BLE MIDI device.
How can I achieve this?
As per official BLE documentation, pairing is initiated by the central device (smartphone etc.) and the peripheral (BLE MIDI device) should simply store the MAC address + security information of the central device that it is currently bonded with.
I am writing a midi polyfill, to bridge Core Midi with Safari. This, in itself, is not a problem. The problem is that the Web Extension will get suspended the moment it's no longer actively called. This means that no callbacks due to midi changes from core midi can be passed back to the web page.
If I use a setInterval call in background.js, then this keeps the extension alive somewhat, but the setInterval self ping will get aborted eventually, making the Extension suspend itself.
I know of a fairly contrived workaround using the container application over XPC, but I am hoping there is a way to keep the Web Extension alive - or at least keep a thread in the same process as the Web Extension alive. Or any such workaround. Setting background to "persistent": true does not seem to make any difference.
Developing for iphone/ipad/mac
I have an idea for a music training app, but need to know of supporting libraries for recognizing a musical note's fundamental frequency in close to real time (100 ms delay) Accuracy should be within a few cents (hundredths of a semi tone)
A search for "music" resolved the core-midi library -- fine if I want to take input from midi, but I want to be open to audio input too.
And I found MusicKit, which seems to be a programmer's API for digging into
Meta questions:
Should I be using different search terms:
Where are libraries listed?
Who are the names in 3rd party libraries.
Hello everyone,
I'm relatively new to iOS development, and I'm currently working on a Flutter plugin package. I want to use the AVFAudio package to load instrument sounds from an SF2 file into different channels. Specifically, I'd like to load individual instruments from the SF2 file onto separate channels.
However, I've been struggling to find a way to achieve this. Could someone guide me on how to load SF2 instrument sounds into different channels using AVFAudio? I've tried various combinations of parameters (program number, soundbank MSB, and soundbank LSB), but none seem to work.
If anyone has experience with AVFAudio and SF2 files, I'd greatly appreciate your help. Perhaps there's a proven approach or a way to determine the correct values for these parameters? Should I use a soundfont editor to inspect specific values within the SF2 file?
Thank you in advance for any assistance!
Best regards,
Melih
Hello,
I have received 3 almost identical crash reports from the App Store. They all come from the same user, and they are spaced just ± 45 seconds apart.
This is the backtrace of the crashed thread:
Crashed Thread: 3
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: Ssssssss [46033]
Thread 3 Crashed:
0 libsystem_kernel.dylib 0x00007ff81b90f196 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007ff81b946ee6 pthread_kill + 263 (pthread.c:1670)
2 libsystem_c.dylib 0x00007ff81b86dbdf __abort + 139 (abort.c:155)
3 libsystem_c.dylib 0x00007ff81b86db54 abort + 138 (abort.c:126)
4 libc++abi.dylib 0x00007ff81b901282 abort_message + 241
5 libc++abi.dylib 0x00007ff81b8f33fb demangling_terminate_handler() + 267
6 libobjc.A.dylib 0x00007ff81b5c67ca _objc_terminate() + 96 (objc-exception.mm:498)
7 libc++abi.dylib 0x00007ff81b9006db std::__terminate(void (*)()) + 6
8 libc++abi.dylib 0x00007ff81b900696 std::terminate() + 54
9 libdispatch.dylib 0x00007ff81b7a6047 _dispatch_client_callout + 28 (object.m:563)
10 libdispatch.dylib 0x00007ff81b7a87c4 _dispatch_queue_override_invoke + 800 (queue.c:4882)
11 libdispatch.dylib 0x00007ff81b7b5fa2 _dispatch_root_queue_drain + 343 (queue.c:7051)
12 libdispatch.dylib 0x00007ff81b7b6768 _dispatch_worker_thread2 + 170 (queue.c:7119)
13 libsystem_pthread.dylib 0x00007ff81b943c0f _pthread_wqthread + 257 (pthread.c:2631)
14 libsystem_pthread.dylib 0x00007ff81b942bbf start_wqthread + 15 (:-1)
In the backtrace of the main thread, I can see that the error is caught by the app delegate which tries to display an alert, but obviously the message has no time to appear. Incidentally (but it's not my main question), I would like to know if it would be possible in such a case to block the background thread for the time the alert is displayed (e.g. using a dispatch queue)?
... (many other related lines)
72 SSUuuuIIIIIIIIIUUuuuu 0x000000010e8089f2 +[NSAlert(Ssssssss) fatalError:] + 32
73 Ssssssss 0x000000010dd5e75b __universalExceptionHandler_block_invoke (in Ssssssss) (SQAppDelegate.m:421) + 333659
74 libdispatch.dylib 0x00007ff81b7a4d91 _dispatch_call_block_and_release + 12 (init.c:1518)
75 libdispatch.dylib 0x00007ff81b7a6033 _dispatch_client_callout + 8 (object.m:560)
76 libdispatch.dylib 0x00007ff81b7b2fcf _dispatch_main_queue_drain + 954 (queue.c:7794)
77 libdispatch.dylib 0x00007ff81b7b2c07 _dispatch_main_queue_callback_4CF + 31 (queue.c:7954)
78 CoreFoundation 0x00007ff81ba62195 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 (CFRunLoop.c:1780)
79 CoreFoundation 0x00007ff81ba21ebf __CFRunLoopRun + 2452 (CFRunLoop.c:3147)
80 CoreFoundation 0x00007ff81ba20ec1 CFRunLoopRunSpecific + 560 (CFRunLoop.c:3418)
81 HIToolbox 0x00007ff8254a5f3d RunCurrentEventLoopInMode + 292 (EventLoop.c:455)
82 HIToolbox 0x00007ff8254a5d4e ReceiveNextEventCommon + 657 (EventBlocking.c:384)
83 HIToolbox 0x00007ff8254a5aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (EventBlocking.c:171)
84 AppKit 0x00007ff81eabfb18 _DPSNextEvent + 858 (CGDPSReplacement.m:818)
85 AppKit 0x00007ff81eabe9c2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 (appEventRouting.m:407)
86 AppKit 0x00007ff81eab1037 -[NSApplication run] + 586 (NSApplication.m:3432)
87 AppKit 0x00007ff81ea85251 NSApplicationMain + 817 (NSApplication.m:9427)
88 dyld 0x00007ff81b5ec41f start + 1903 (dyldMain.cpp:1165)
In all 3 reports, another thread indicates that it is sending or receiving a MIDI data (it's exactly the same backtrace in the 3 reports):
Thread 1:
0 libsystem_kernel.dylib 0x00007ff81b908552 mach_msg2_trap + 10
1 libsystem_kernel.dylib 0x00007ff81b9166cd mach_msg2_internal + 78 (mach_msg.c:201)
2 libsystem_kernel.dylib 0x00007ff81b90f584 mach_msg_overwrite + 692 (mach_msg.c:0)
3 libsystem_kernel.dylib 0x00007ff81b90883a mach_msg + 19 (mach_msg.c:323)
4 CoreMIDI 0x00007ff834adfd50 XServerMachPort::ReceiveMessage(int&, void*, int&) + 94 (XMachPort.cpp:62)
5 CoreMIDI 0x00007ff834b118c5 MIDIProcess::MIDIInPortThread::Run() + 105 (MIDIClientLib.cpp:204)
6 CoreMIDI 0x00007ff834af9c44 CADeprecated::XThread::RunHelper(void*) + 10 (XThread.cpp:21)
7 CoreMIDI 0x00007ff834afae9f CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 77 (CAPThread.cpp:324)
8 libsystem_pthread.dylib 0x00007ff81b9471d3 _pthread_start + 125 (pthread.c:893)
9 libsystem_pthread.dylib 0x00007ff81b942bd3 thread_start + 15 (:-1)
I wonder if this MIDI activity may be related to the crash, even if it doesn't occur in the crashed thread.
I also wonder if the dispatch block starting the backtrace of the thread 3 is the same that leads to the thread 1 (to open the NSAlert), which would mean that it's after the error, or if it's a dispatch block into which the error occurs.
Finally,
2024-03-25_13-04-40.6314.crash
I wonder if std::terminate() could indicate a problem in C++ codes because I have some part of the application written in C++, and it would be a clue.
More generally, is it something in these backtraces that can help me to find what's the problem ?
Any help greatly appreciated, thanks!
-dp
I connect two AVAudioNodes by using
- (void)connectMIDI:(AVAudioNode *)sourceNode to:(AVAudioNode *)destinationNode format:(AVAudioFormat * __nullable)format eventListBlock:(AUMIDIEventListBlock __nullable)tapBlock
and add a AUMIDIEventListBlock tap block to it to capture the MIDI events.
Both AUAudioUnits of the AVAudioNodes involved in this connection are set to use MIDI 1.0 UMP events:
[[avAudioUnit AUAudioUnit] setHostMIDIProtocol:(kMIDIProtocol_1_0)];
But all the MIDI voice channel events received are automatically converted to UMP MIDI 2.0 format. Is there something else I need to set so that the tap receives MIDI 1.0 UMPs?
(Note: My app can handle MIDI 2.0, so it is not really a problem. So this question is mainly to find out if I forgot to set the protocol somewhere...).
Thanks!!
Calling MIDIFlushOutput on a network endpoint is not cancelling events scheduled with future timestamps -- they continue to send.
e.g.
func send(eventLists: [MIDIEventList]) {
let outputPortRef = ...
let networkDestination = ...
for var eventList in eventLists {
MIDISendEventList(outputPortRef, networkDestination.objectRef, &eventList)
}
}
...
MIDIFlushOutput(networkDestination.objectRef)
I'm seeing that MIDIFlushOutput does successfully cancel scheduled events on a non-network endpoint. How can I clear all scheduled outgoing events over a MIDI Network connection?