While vigorously testing out my iOS app with a MIDI controller keyboard, I sometimes generate CoreMIDI input that is clearly garbage. Here is the code I use to iterate over the MIDIPacketList: let numPackets = packetList.numPackets os_log(.info, log: log, "processPackets - %d", numPackets) var packet: MIDIPacket = packetList.packet for index in 0..<numPackets { &#9;os_log(.info, log: log, "packet %d - %d bytes", index, packet.length)   // Filter out garbage (zero or really big sizes of 26624)   if packet.length == 0 || packet.length > 30 { &#9;  os_log(.error, log: log, "suspect packet size %d", packet.length)     break   }   processPacket(packet, controller)   packet = MIDIPacketNext(&packet).pointee } If I pound away on the keys and do a lot of pitch bends and mod wheel spins, I can sometimes get what appears to be garbage, with packets of either 0 or 22624 bytes (which is curiously 0x6800 hex). As above, I currently stop processing the MIDIPacketList when this happens, but that is clearly not a great solution. Anyone else encounter something like this?

Curious if anyone understands why feedback parameter supports *negative* percentage values. As far as I can tell, there is no audible difference between the positive and negative percentages.

I have a working AUv3 AUAudioUnit app extension but I had to work around a strange issue: I found that the internalRenderBlock value is fetched and invoked before allocateRenderResources() is called. I have not found any documentation stating that this would be the case, and intuitively it does not make any sense. Is there something I am doing in my code that would be causing this to be the case? Should I *force* a call to allocateRenderResources() if it has not been called before internalRenderBlock is fetched? Thanks! Brad

My iOS app using CoreMIDI is able to receive MIDI messages from various keyboards, but I have just received a note from a customer notifying me that my app does not appear to receive MIDI messages from his Casio CT-S1 keyboard. I am stymied on how to diagnose and fix this issue. Clearly there must be something amiss in my CoreMIDI integration. I thought perhaps someone else might have encountered a similar odd situation such as this. If it helps, here is my CoreMIDI integration code. Thanks! Regards, Brad

Curious if there is a sound way for an AUv3 component to identify how many other instances of it that are running on a device. For instance, if GarageBand has 4 tracks and all of the tracks use the same AUv3 component, is there a sound way for each one to obtain a unique index value? Thanks!

In Xcode 14, I had somewhat usable counterpart navigation available for the C++ files in my Swift package -- https://github.com/bradhowes/SF2Lib It was not perfect and would sometimes get confused, but from an include file I could use ^⌘↓ to show the related C++ file. Now in Xcode 15, this no longer works. When I click on the "Navigate to Related Items" icon in the editor window, it shows various files but the "Counterparts" entry is greyed out. I now have to use "Open Quickly", type a file name and locate the right one. I suspect this is due to my code layout and/or some missing setting in my Package.swift file that is not enabling this, but I am at a loss as to what it could be. I have erased the derived data for the project and rebuild everything from scratch. Everything builds and all test pass, but the Xcode navigation among related files is for now not working. Hope someone has a fix for this. Thanks! Brad