I've been seeing this crash pretty regularly for a long time now. It happens pretty randomly and always points to the same place. Here's a backtrace:
frame #0: 0x0000000101fc6dc0 HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] $defer #1 (p=CoreMIDI.MIDIPacket @ 0x00000001219ffef0, idx=<unavailable>) -> () in closure #1 () -> Swift.Optional<__C.MIDIPacket> in (extension in AudioKit):__C.MIDIPacketList.makeIterator() -> Swift.AnyIterator<__C.MIDIPacket> at MIDIPacketList+SequenceType.swift:26:19 [opt]
frame #1: 0x0000000101fc6d64 HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] closure #1 (idx=<unavailable>, p=<unavailable>) -> Swift.Optional<__C.MIDIPacket> in (extension in AudioKit):__C.MIDIPacketList.makeIterator() -> Swift.AnyIterator<__C.MIDIPacket> at MIDIPacketList+SequenceType.swift:25 [opt]
frame #2: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] reabstraction thunk helper from @escaping @callee_guaranteed () -> (@unowned Swift.Optional<__C.MIDIPacket>) to @escaping @callee_guaranteed () -> (@out Swift.Optional<__C.MIDIPacket>) at <compiler-generated>:0 [opt]
frame #3: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] generic specialization <__C.MIDIPacket> of Swift._ClosureBasedIterator.next() -> Swift.Optional<A> at <compiler-generated>:0 [opt]
frame #4: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] inlined generic function <__C.MIDIPacket> of protocol witness for Swift.IteratorProtocol.next() -> Swift.Optional<A.Element> in conformance Swift._ClosureBasedIterator<A> : Swift.IteratorProtocol in Swift at <compiler-generated>:0 [opt]
frame #5: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] generic specialization <Swift._ClosureBasedIterator<__C.MIDIPacket>> of Swift._IteratorBox.next() -> Swift.Optional<A.Element> at <compiler-generated>:0 [opt]
frame #6: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(_:name:) [inlined] generic specialization <__C.MIDIPacket> of Swift.AnyIterator.next() -> Swift.Optional<A> at <compiler-generated>:0 [opt]
* frame #7: 0x0000000101fc6d2c HALO`closure #1 in AKMIDIInstrument.enableMIDI(packetList=<unavailable>, self=0x00000002805f1290) at AKMIDIInstrument.swift:46 [opt]
frame #8: 0x0000000101fb7768 HALO`thunk for @escaping @callee_guaranteed (@unowned UnsafePointer<MIDIPacketList>, @unowned UnsafeMutableRawPointer?) -> () at <compiler-generated>:0 [opt]
frame #9: 0x00000001c481e398 CoreMIDI`LocalMIDIReceiverList::HandleMIDIIn(unsigned int, unsigned int, void*, MIDIPacketList const*) + 164
frame #10: 0x00000001c481e230 CoreMIDI`MIDIProcess::RunMIDIInThread() + 200
frame #11: 0x00000001c481cc88 CoreMIDI`XThread::RunHelper(void*) + 28
frame #12: 0x00000001c47ff6e4 CoreMIDI`CAPThread::Entry(CAPThread*) + 92
frame #13: 0x00000001999eb914 libsystem_pthread.dylib`_pthread_start + 168
Our app subclasses AKMIDIInstrument and plays/stops notes by overriding the existing play/stop functions. Our sequencer connection is just:
public static func setMIDIOutput(_ endPoint: MIDIEndpointRef, forTrack track: MusicTrack) {
let status = MusicTrackSetDestMIDIEndpoint(track, endPoint)
if status != noErr {
print("Error setting MIDI output for track: \(status)")
}
}
where endPoint is our AKMIDIInstrument subclass' midiIn.
UPDATE: Thinking about the setMIDIOutput function above; is there any risk involved in assigning and potentially changing endpoints like this?