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.

Are you looking at MIKMIDI.framework or MIKMIDI.xcframework file? For an Intel machine I went into the xcframework directory (obtained from the GitHub site ( MIKMIDI site - https://github.com/mixedinkey-opensource/MIKMIDI ) marked as the MIKMIDI release 1.7.1 on 14-August-2020. I then extracted MIKMIDI.xcframework/macos-x86_64/MIKMIDI.framework and copies it to my project. I was then able to add the framework in my project. The executable in the framework is apparently Intel only rather than Universal (Intel plus ARM). Therefore, the build only works on an Intel machine. However, after creating the app on an Intel machine, I am able to copy it to an ARM MacBook Pro and execute it through Rosetta. (My project is BRossTools/BRossTools in BradleyRoss/ObjectiveC-Examples - https://github.com/BradleyRoss/ObjectiveC-Examples -- use the Playpen branch.) Let me know if you have any luck building a Universal version of the MIKMIDI framework. Thanks.

The problem with the Apple Layout tools is the poor quality of the documentation. In the past, I have found looking through the Javadoc documentation on their auto layout tools and tried mapping it back to the Apple documentation. Actually, there was a video on "container views" from Apple a few years ago https://developer.apple.com/videos/play/wwdc2017/218/ which was interesting but probably helped me more than it would others due to my Java background. Using a graphic tool like Interface Builder can make it difficult to understand what the code is doing since you don't know what actions in IB are really doing to the code. Automatic layout tools like the container views can also make it much easier to reuse and modify code. This is going to be more of an issue as Apple moves to trying to have common code bases on iOS and MacOS. There are a lot of tricks that you can do with the automatic layout tools allowing users to customize their views. A big advantage is to write your own views that can encapsulate view within other views. A example would be adding scrolling to other views. The advantages become much more apparent when you have a lot of experience in coding large projects (over 100,000 lines of efficiently written code).

Is there another way to use Doxygen on the code generated in Xcode? Up to this time, I have been downloading Doxygen from doxygen.nl and running it myself. Is there an Apple document that describes auto documenters (HeaderDoc Doxygen, etc.) with Objective-C/Cocoa? From the comments, I'm not sure if I should be using a modified Apple specific version of Doxygen.

I have found the best approach is frequently to look for open source projects that have functions related to what you want. My notes are in an awful mess and will take a while to make presentable. You might want to look at some of the following web pages. https://github.com/mixedinkey-opensource/MIKMIDI This had some Objective-C code for handling MIDI https://github.com/DerekCook/CoreMidi4J This was part of an attempt to improve the Java interface with Apple MIDI using dynamically linked code. Look at the C code in the example. I'll try to make some more stuff available when I organize it.