Do you know what the status bytes are for the first message in the incredibly long packets. These could be SystemExclusive messages which can be generated by the system automatically. Perhaps they are status dumps. The critical factor is the first twenty or so bytes in the packet.

"noteSee https://bradleyross.github.io/ObjectiveC-Examples/Documentation/BRossTools/FunctionalArea.html A major problem is that MIDISend is not for working with EventList items. You have to use MIDISendEventList. There are actually 3 different APIs listed under CoreMidi in the documentation. The first set does not use blocks for processing the MIDI messages. However, this results in a lot of timing problems. The second set uses blocks for processing the messages. The third set uses Universal MIDI Packets to handle both MIDI 1 and MIDI 2. The page above is my attempt to split the items into groups. One thing is that the individual words in UMP apparently, according to one of the books, have the bytes in the words in native-endian order. It appears that the order of the bits is scrambled and it may be scrambled differently on different system.

A number of the CoreMIDI functions have been modified to use blocks. The block is then run under the high priority queue used for running the virtual devices. Notification of changes to the MIDI configuration has also been replaced by a block. See https://bradleyross.github.io/ObjectiveC-Examples/Documentation/BRossTools/FunctionalArea.html

Try my project in the BRossTools folder of the https://github.com/bradleyross/ObjectiveC-Examples GitHub Repository to see if you can get to the keyboard using MacOS. Documentation in https://bradleyross.github.io/ObjectiveC-Examples. I would be delighted to talk with you. I am finding the documentation extremely difficult to use.

See https://bradleyross.github.io/ObjectiveC-Examples/Documentation/BRossTools/FunctionalArea.html. It looks like MIDIClientCreate doesn't work right and you have to use MIDIClientCreateWithBlock and my project is in https://github.com/bradleyross/ObjectiveC-Examples in the BRossTools. I would love to talk to people on how to get this working to do more. It appears that some functions have to run in a high-priority thread and others can't run in a high-priority thread.

I believe that you have to ignore the "deprecated" annotations and use the information in https://bradleyross.github.io/ObjectiveC-Examples/Documentation/BRossTools/FunctionalArea.html. The project is in the BRossTools folder in the BradleyRoss/ObjectiveC-Examples GitHubrepository.

I found the problem. One of the subroutines was indirectly calling one of the UI methods. I placed code in place to insure that it would run on the main Modified code to insure execution on main thread

My understanding is that this is a general MIDI artifact. Note 60 is Middle C -- https://www.reddit.com/r/musictheory/comments/8fwoti/why_does_middle_c_midi_note_60/ A list of instruments for the General MIDI set is at https://soundprogramming.net/file-formats/general-midi-instrument-list/ If you still have questions, could you send me a list of other questions. I have some materials, an can probably give you some more sources.

My problem is that the documentation says that MIDIInputPortCreateWithProtocol is only available in macOS 11.0 or later. This means that is only usable in BigSur. I am trying to create some sample MIDI programs, but I am getting errors. The code that I am trying - https://developer.apple.com/forums/content/attachment/d23aaa28-13aa-4369-be90-63e73fe85544 When I run that code, I get the following error. BRossTools[2569]: BUG IN CLIENT OF LIBDISPATCH: Assertion failec: Block was expected to run on queue [com.apple.main-thread] The error when I depressed a key on the keyboard. Who do I send feedback to about the docs. I have a number of issues. Does anybody have a short example that reads MIDI signals from a keyboard. I can put my working code on GitHub if people want to look at it. All of the tutorials seem to be years out of date.

Did you ever find a solution to this. I seem to be having something similar. In one case, I had a message in the log with the statement BRossTools[2569]: BUG IN CLIENT OF LIBDISPATCH: Assertion failed: Block was expected to run on queue [com.apple.main-thread] I'm going to try to get things a little more organized and then I can post my code. It seems to occur when I try to capture a key press on the MIDI keyboard

Let me list just a few of my experiences. The Desktop, Documents, and Downloads directories have some additional rules. If your executable is located in one of these places, see if moving it will help. Even if the main Mach object is a universal format with ARM and Intel, it may be that some of the embedded frameworks don't contain ARM version. I had some programs with this situation try to run using ARM because the main program was universal but then fail to open when it tried to load the frameworks. Make sure that it runs on an Intel MacOS system. There were some changes with Big Sur, and you want to make sure it isn't those issues burning you rather than the ARM/Intel issue. Make sure that try setting the file to use Rosetta using the options in "get info" in the finder. Some of the options for granting the programs privileges won't allow the privileges to be executed until you have run the program. For example, some programs won't let you read or write the Desktop or Documents directory. However, after you have read and written files in other directories, it will let you add privileges. Note that a program that contains a save or open panel that allows all directories will sometimes need privileges even if you aren't using those directories at the time. Please note that having 777 permissions on the files and directories will not grant you full privileges. There are other rules that do not belong to the rwx (read, write, execute) security domain. There have also been with network attached shares. Some programs will treat networked attached files differently. I believe that somebody mentioned Samba and that could be a problem. There have also been problems on the remote Apple directories. Some of these have been mentioned in other posts but a lot of them don't follow the logical rules that you think they are following. Please remember Murphy's Correlary: Murphy was an optimist when he wrote his eponymous law.