MIDIApps: a MIDI monitor and a SysEx librarian for macOS

Two applications and a shared foundation

This repository is the source code for two macOS applications. MIDI Monitor is an application for monitoring MIDI data as it goes in and out of the computer, and SysEx Librarian is an application for sending and receiving MIDI system exclusive messages, the sysex messages that control a synthesiser's patch settings.

The README is clear about who needs it. You do not need any of this if you just want to use the apps, and you need the source if you want to play with the code, customize the application, or use parts of the code in your own project. The code is open source under the BSD licence, and the README points at the LICENSE file for the legal details.

The interesting part of the repository is not the applications, it is the framework layer underneath them. SnoizeMIDI is a Cocoa framework for dealing with CoreMIDI, and SnoizeMIDISpy is a CoreMIDI driver and a framework that can observe the MIDI sent to any destination on the system. The applications are the demonstration, and the frameworks are the reusable part.

The project is written in Swift and Objective-C, with a CoreMIDI driver in C++, and it is tied to the current toolchain. The README says the project is intended to be used with an up-to-date Xcode version, like Xcode 15.0 with the macOS 14.0 SDK, and that if you need to run it on an earlier Xcode you should try checking out older revisions. The default branch is main, the last push was on 2026-05-13, and there are no GitHub releases.

The homepage is snoize.com, and the contact for questions is Kurt Revis.

Building it is five steps, one of them a signing setting

The build instructions are short, and the third step is the one that stops people.

The first step is to initialise the submodules, with git submodule update --init --recursive, which matters because the HexFiend source is a submodule and the interface draws hex dumps with it. The second is to open MIDIApps.xcworkspace with Xcode, and the workspace rather than a project file, because there are several projects and the workspace is what wires them together.

The third step is the signing configuration. You open Configurations/Snoize-Signing.xcconfig and change DEVELOPMENT_TEAM to the Team ID of your Apple Developer account, with a pointer to the file for the details. Until that is set the build has no signing identity, and the error you get is a signature failure rather than anything that points at the xcconfig.

The fourth is to pick the scheme. In the Scheme popup menu in the toolbar you select either MIDI Monitor or SysEx Librarian, because the workspace builds both and the scheme decides which one you run. The fifth is to build and run.

The overall structure of the source tree is given in the README, and it is worth knowing before you open anything, because the names are not obvious. Applications holds MIDIMonitor and SysExLibrarian, each with its own Xcode project, MIDIMonitor.xcodeproj and SysExLibrarian.xcodeproj. Configurations holds the xcconfig files. Frameworks holds SnoizeMIDI and SnoizeMIDISpy. Third Party holds the HexFiend submodule. And Updates holds the server-side files that make the application update mechanism work. There is also a Packaging directory at the top level of the repository, outside the list in the README.

SnoizeMIDI is the CoreMIDI code you would otherwise write

The SnoizeMIDI framework is described as containing code for dealing with CoreMIDI in a Cocoa app, and the README lists four things it does.

Finding MIDI devices, sources and destinations. Creating streams of input and output data. Hooking them up to inputs and outputs. And parsing incoming MIDI data into separate messages.

That last item is the one that decides whether the framework is worth taking. Raw CoreMIDI delivers a byte stream, and a MIDI byte stream is a sequence of variable-length status messages that have to be reassembled, including the running status cases and the system exclusive blocks that have their own framing. Every application that reads MIDI writes that parser, and every application that writes it has to decide how to chunk a long message across a buffer boundary. SnoizeMIDISpy, the other framework, does the same parsing work for the traffic it intercepts, so the two have to agree about framing, and a shared framework is how they do.

The README says the framework is used by both apps, and that you can use it in your own apps as well. That is the sentence that makes this repository interesting to an engineer who is not building a MIDI monitor, because the device discovery and stream management code is the part that is tedious and the part that is stable, and the applications are the part that is specific to snoize's needs.

Both applications themselves are Cocoa and written in Swift, and the two frameworks are the older, lower-level layer underneath them.

SnoizeMIDISpy installs a driver that watches every destination

SnoizeMIDISpy builds two things, a CoreMIDI driver and a framework, and the driver is the unusual part of this repository.

The CoreMIDI driver can spy on the MIDI sent to any destination in the system by any app, and the README points at the MIDIDriverEnableMonitoring() function in CoreMIDIServer/MIDIDriver.h for the details. The driver can then pass the MIDI data to another application.

That is a system-level capability rather than an application-level one. Instead of asking CoreMIDI for a device and reading its input, the driver sits in the path of the system's MIDI output and observes what is being sent, regardless of which application is sending it. It is the mechanism that lets MIDI Monitor show traffic going to a hardware destination that no other app can read, and it is why the framework has to manage the communication between the app and the driver and provide the app with an easy way to install the CoreMIDI driver when necessary.

The README is honest about the current usage. This code is currently only used by MIDI Monitor, but it could be useful in other contexts, and MIDI Monitor contains some code to channel the spy MIDI data into the rest of the SnoizeMIDI stream system, so it acts just like any other MIDI source. That last point is the design detail worth noting, because it means the intercepted traffic is not a special case in the application, it enters the same pipeline as everything else.

The languages are split by role. The driver is written in C++, and the framework is C and Objective-C, and the README says you should be able to easily use the code from an application.

Two dependencies, one of them a submodule

The Third Party directory contains the git submodule for HexFiend, which is used to display hex dumps in various views, and the README repeats the instruction to run git submodule update --init --recursive if you do not see the HexFiend submodule. A hex dump is the natural way to show MIDI bytes, since the protocol is a byte protocol with running status and multi-byte values, and HexFiend is a well-established open source hex viewer, so borrowing it rather than writing a viewer is a sensible call.

The Updates directory contains the server-side files used to make app updates work, via Sparkle, and the README says you do not need to touch these. The mechanism is the standard one for a Mac application outside the App Store, an appcast on a server and a client that checks it. The app targets use Sparkle as a package dependency via Swift Package Manager, and the note is that Xcode should automatically get the package for you, so there is no step to perform there.

The Configurations directory has a different job. It contains the xcconfig files used to coordinate build settings across all the Xcode projects, which is what keeps the shared frameworks, the deployment target and the signing identity consistent between the two applications and the frameworks they both use.

So the dependency picture is small and conventional: HexFiend for the hex view, Sparkle for updates, and the platform's own CoreMIDI for everything to do with MIDI itself.

Maintenance, and what the project asks of you

The state of the repository is easy to summarise. The last push was on 2026-05-13, the default branch is main, the project is not archived, and it publishes no GitHub releases, so the two applications are distributed as finished binaries from the site rather than as build artefacts you fetch from the repository.

The thing that will decide whether you can build it is the toolchain. The project targets a current Xcode, with Xcode 15.0 and the macOS 14.0 SDK given as the example, and the fallback for an older Xcode is to check out an older revision. That is a normal statement for a Mac project, and it is the price of using a recent SDK, but it does mean the build is coupled to the version of macOS you develop on.

The second thing the project asks of you is an Apple Developer account, at least for the signing configuration. The DEVELOPMENT_TEAM value in the signing xcconfig is what turns a local build into something Xcode will run, and it is the one step in the instructions that is not a command you can copy.

The README ends by pointing questions at Kurt Revis, with an email address, which is a reasonable arrangement for a project that has a single maintainer and a specific audience: people who want to monitor their MIDI traffic, manage their synthesiser patches, or reuse a well-tested CoreMIDI layer in their own Mac application.

Editorial conclusion

Adopt SnoizeMIDI if you are writing a macOS application that needs to find MIDI devices, open streams, parse incoming data into messages and expose them to your code, because that is exactly what the framework does and the README says you can use it in your own apps. Do not adopt the repository as a whole without checking the toolchain, because the project is tied to a recent Xcode and the macOS SDK, and an earlier Xcode means checking out an older revision. Before you build, set the development team in the signing configuration, since the build will not sign without it, and initialise the submodules, because the HexFiend source is what draws the hex dumps in the interface.

Frequently asked questions

Official sources

1. Issues
2. krevis/MIDIApps on GitHub
3. License: BSD-3-Clause
4. Project website
5. README