ShowMIDI: a MIDI monitor that shows the current state, not a log

ShowMIDI draws the traffic instead of printing it

Conventional MIDI monitoring means reading a log. Every message arrives with a timestamp, you scroll, you mentally group the lines that belong together, and you try to work out which of them matter. The project's own framing is that it fills a void among the available monitoring solutions, and that instead of wading through logs of MIDI messages to correlate relevant ones, it visualises the current activity and hides what you no longer care about.

So the unit of display is a live state, not an event. A device that sends a note and then stops sending anything is still shown, still on screen, with its last state. That difference is what makes the view glanceable, and it is why the project includes a side by side animation comparing a traditional monitor with its own display.

The heavy lifting is done by JUCE, and the repository shows how much of JUCE is in play. The root contains a JUCE directory and a JuceLibraryCode directory, a showmidi.jucer project file, an Interface directory, Source, Fonts, Themes, Assets, Patches, Installers, Scripts and a libs directory. The .gitmodules file, together with the JUCE directories in the tree, shows that the framework is vendored as a submodule rather than consumed from a package manager.

That vendoring is what makes the plugin formats possible. The same C++ code base is compiled into a standalone application and into MIDI effect plugins that load in a DAW.

The columns cover notes, controllers, MPE and clock messages

The list of what the display covers is long enough to be the real specification of the tool. Devices are shown as columns, and inside a column the message types get their own representation.

At the note level you get Note On with velocity and Note Off with velocity, shown as ON and OFF. Control Change appears as CC, and there is a separate entry for Hi-Res 14-bit Control Change, HRCC, which is the high resolution counterpart some controllers use for smooth parameter sweeps. Pitch Bend Change shows as PB, Program Change as PRGM.

There are two pressure types, and they are not the same thing. Channel Pressure is CP and applies to the whole channel, while Polyphonic Key Pressure is PP and applies to a single note. Registered and Non-Registered Parameter Numbers are shown as RPN and NRPN, which matters when you are working with a controller whose parameters are not plain CC numbers.

MPE has its own group, with MPE MGR for the configuration message, MPE LZ and MPE UZ for the lower and upper zone. MPE is where a monitor earns its keep, because per note expression generates a lot of traffic that a log makes tedious to read.

Timing is covered as well: Timing Clock shown as BPM, plus Clock Start, Clock Continue and Clock Stop, and System Exclusive as SYSEX, which is the message type that most often carries the payload a developer actually needs to inspect.

Channels float to the top and auto-hide when they go quiet

The interaction model is where a live monitor earns its keep, and the documentation is precise about it.

When an incoming message first appears on a MIDI channel, that channel appears at the top of the MIDI device column. For as long as the channel is displayed it keeps that order. When a channel is auto-hidden through inactivity, the next activity on it brings it back to the top of the column. In other words, position encodes recency, and you never have to hunt for the channel that just woke up.

Devices are managed from the left side panel, which can be expanded to show or hide individual devices. Holding the alt or option key while clicking a device changes the visibility of all the devices, which is the fast path for isolating one device in a busy rig.

A few more controls are worth memorising. Pressing the spacebar pauses the MIDI data stream, and pressing it again un-pauses. The data can be displayed either as horizontal lines or as scrolling graphs, and the visualisation icon toggles between them, with the v key doing the same from the keyboard. The reset button, or the delete or backspace key, clears what is displayed quickly.

The plugin versions load in any DAW that supports MIDI effect plugins. The documentation warns that some plugin formats, VST3 for instance, might filter out certain MIDI messages, so the plugin view can be less complete than the standalone application.

Installing is a brew formula or a signed release binary

The quickest route on macOS is Homebrew, using a tap.

brew install gbevin/tools/showmidi

For other platforms the project points at the release section of the repository, where pre-built binaries are published, and it also notes that you can build it yourself by looking in the Builds directory in the sources.

Windows releases are signed through SignPath.io, with a certificate provided by the SignPath Foundation, and the macOS releases are signed and notarized with Apple Developer ID certificates held by Uwyn, LLC. Releases are built on GitHub Actions from the sources in the repository, and every signing request is approved manually by the committer, reviewer and approver, who is also the person who maintains the repository. The documentation states that SignPath receives the identity of the person approving the request and the metadata of the artefacts being signed, and that no data about users is collected or shared.

That is a small but meaningful detail for anyone deploying a diagnostic tool inside a company: the signing pipeline is described as manual, so a release depends on one person's approval, and the vendor relationships are named rather than implied.

On versions, the release list shows 1.0.0 on 2024-07-08 and 1.0.1 on 2024-07-10, after 0.9.0 on 2024-01-06. The repository is not archived and the last push was on 2026-10-19, so the source tree is still moving even though the published binaries date from 2024.

Building on Linux needs a VST2 SDK you are not allowed to redistribute

The source build path is documented in enough detail to be useful, with one real blocker. ShowMIDI relies on Git submodules for the external dependencies, so the first step after cloning is to initialise them.

git submodule update --init --recursive

The Linux build then needs a set of system packages. On Ubuntu the documentation gives this list.

sudo apt install build-essential pkg-config libasound2-dev \
  libfreetype6-dev libx11-dev libxrandr-dev \
  libxinerama-dev libxcursor-dev

The blocker is the VST2 SDK. You need to obtain a version yourself, put it where the compiler can find it, and place the folder at libs/vst2 in the source repository. The documentation is explicit about why: the SDK is not allowed to be distributed, so it is not included. Searching online for vst2.x/aeffect.h is suggested as a way to find a copy.

After that the build happens in the LinuxMakefile directory.

cd Builds/LinuxMakefile
make CONFIG=Release

The resulting binary is left in the Builds/LinuxMakefile/build directory, and it can be moved anywhere, for instance into /usr/local/bin.

sudo mv build/ShowMIDI /usr/local/bin

So the build is a two step affair for anyone on Linux, and one of the steps requires a licence-restricted SDK that the project cannot hand you.

Themes are SVG files you can edit inside the app

Appearance is handled by a set of themes, and the project treats them as user-editable rather than fixed. The application ships with a handful of themes, more are planned, and the documentation says you can edit, create and save themes yourself in the application, with an invitation to submit them to the maintainer.

The included themes live in the Themes directory of the repository, and there is a practical warning attached: download the raw SVG files, because a download that is not the raw file might not contain the right information. The listed set includes bstation, classic light, darcula, dark, disco, light and mouha.

The repository also has a Fonts directory and an Assets directory, which together with the Themes directory suggests that the visual design is a first class part of the project rather than a hard-coded afterthought. The Design directory holds the artwork used in the README, including the line and graph views of version 1.0.0.

The UI design is credited to Stephen Petoniak, and the application itself was created by Geert Bevin, and the README points to the repository as the project website while linking his personal site in the credits. A single named designer and a single maintainer is worth knowing, because it matches the manual signing approval described earlier.

GPL-3.0 and the case against a log-based monitor

The licence is GPL-3.0, and for a diagnostic tool that is the part of the decision that deserves a look rather than a glance. The COPYING.md file at the repository root holds the terms. A GPL application used as a standalone internal tool is a different proposition from GPL code linked into a product you distribute, and anyone embedding ShowMIDI or its plugin into a shipped title needs to read those terms rather than assume the app is a freebie.

Against the log-based alternative, the difference in approach is one of representation. A monitor that records every message gives you a complete and ordered history, which is what you want when you are reconstructing what happened at a particular moment, when you need to diff two takes, or when a bug only shows up once every few hundred events. The cost is that the volume of output forces you to read.

ShowMIDI inverts that. It keeps the current state of each channel visible, puts the recently active channel at the top, and lets inactive channels drop out of sight. The information you lose is the exact history; the information you gain is the ability to watch behaviour as it happens. For tuning a controller, checking a plugin's output or debugging an MPE mapping, that trade is usually the right one. For reconstructing a past event, it is the wrong choice, and you would want a monitor that logs.

Either way, the plugin caveat applies in both directions: if your DAW host filters certain MIDI messages, a visualization cannot show you what never reached it.

Editorial conclusion

ShowMIDI suits a plugin or hardware developer who needs to see note, controller and MPE traffic as live state instead of a wall of log lines, and the Homebrew formula plus signed release binaries make it a low friction install. It is the wrong tool when you need a complete, ordered record of every message, because it hides channels that go quiet, and the plugin build is a lossy view since some hosts filter messages. Before adopting it, check that the JUCE based build starts on your platform, and if you plan to build from source on Linux, place the VST2 SDK at libs/vst2 because it cannot be redistributed with the repository.

Frequently asked questions

Official sources

1. gbevin/ShowMIDI on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases