m8c: a remote display client for the Dirtywave M8 Tracker

The M8 Tracker screen, moved to your desktop

The Dirtywave M8 Tracker is a portable sequencer and synthesizer with eight tracks of assignable instruments, using engines such as FM, waveform synthesis, virtual analog, sample playback and MIDI output, and it is inspired by the Game Boy tracker. m8c is the remote display client for that hardware. It mirrors the M8 display on your computer, enables keyboard and gamepad control, and can route audio to your computer. The README lists the uses as recording, streaming, larger screens and alternative input methods, and that list is the honest value proposition. A hardware tracker with a small screen is awkward to film for a video and impossible to read from across a desk, so the client takes the display and the sound and leaves the sequencer in your hands. The M8 itself is described as inspired by Little Sound DJ's Game Boy tracker, which is the lineage the client inherits along with the hardware.

Two routes to the device: M8 USB or Teensy headless

There are two supported ways for the client to talk to the tracker. The first is the M8 hardware over USB. The second is the M8 Headless firmware running on a Teensy microcontroller, which is the same firmware project the README links for people who want the tracker without the built-in screen, and m8c is explicitly supported against it. The distinction matters in practice, because the headless build has no display of its own, so the client is not a convenience for it, it is the only way to see what is happening. The README also asks readers to support Dirtywave by buying the hardware, and points at the creator Trash80's Patreon, which is a reasonable thing for a client project to say about itself. The credits list names the same people for the hardware and the original fonts that were converted to a bitmap for use in the program.

Getting the binary: releases, AppImage, Nix

The quick start is three steps. Download the prebuilt binary for your platform from the releases section, connect the M8 or a Teensy running the headless firmware to your computer, and run the program, which should detect the device automatically. Prebuilt binaries exist for Windows and for recent versions of macOS, and on Windows the README warns that Defender may complain about an unrecognised app on first run, with a click through More info and Run anyway. Linux has three options, of which the AppImage is the least fiddly. You download the .AppImage from the releases, make it executable and run it:

chmod +x m8c-*.AppImage

./m8c-*.AppImage

The AppImage is portable and needs no installation. NixOS users have two documented paths, a classic environment install pointing at the repository archive:

nix-env -iA m8c -f https://github.com/laamaa/m8c/archive/refs/heads/main.tar.gz

or, with flakes and the nix command, running it straight from the GitHub reference:

nix run github:laamaa/m8c

Building from source needs SDL3 and libserialport

The source build is plain C with a Makefile, and the dependency list is short: git, gcc, pkg-config, make and the development headers for SDL3 and libserialport. The Makefile itself confirms the shape, since it locates the sources under src/, finds headers for dependency tracking, and pulls the SDL3 and libserialport flags in through pkg-config with a -DUSE_LIBSERIALPORT define. On Ubuntu 25.04 and later SDL3 is in the official repositories:

sudo apt update && sudo apt install -y git gcc pkg-config make libserialport-dev libsdl3-dev

On older Ubuntu releases there is no official SDL3 package, so the README says you will likely need to build the library yourself, pointing at the SDL build instructions. The macOS route assumes Homebrew and installs the same set of tools:

brew update && brew install git gcc make sdl3 libserialport pkg-config

On Windows the assumed environment is MSYS2 with the MINGW64 packages for gcc, pkg-config, make, SDL3 and libserialport. Once the dependencies are in place the build is a clone, a make and a run.

make

./m8c

Picking a device when several are plugged in

If you have more than one M8 connected, or you want to run the client several times, the program can list what it finds:

./m8c --list

The output is one INFO line per device, showing a serial port path such as /dev/cu.usbmodem124709801. You then pin the client to one of them with the --dev option:

./m8c --dev /dev/cu.usbmodem124709801

The README adds an important caveat about that option. It can force detection of any serial device by name, which is useful when libserialport cannot read the correct USB identifiers, and it mentions some Windows 11 setups as an example. The practical consequence is that if --list returns nothing, you may need to look up the device name in Device Manager and pass it to --dev by hand. That is a real workflow difference from the automatic path, and it is the kind of detail that decides whether a device works at all on a given machine.

Keyjazz turns the computer keyboard into a tracker keypad

The key mappings are laid out explicitly. The arrow keys move, z or left shift is shift, x or space is play, a or left alt is opt, and s or left ctrl is edit. Beyond that, Alt+Enter toggles full screen and windowed mode, Alt+F4 quits, Delete is opt plus edit which deletes a row, Esc toggles keyjazz on and off, r or the select, start, opt, edit combination resets the display when it glitches, F1 opens a config editor, F2 toggles an in-app log overlay, and F12 toggles audio routing. The most interesting mode is keyjazz, which allows entering notes with a keyboard in the old school tracker style. The layout is two octaves starting from the keys Z and Q, and while keyjazz is active the regular a, s, z and x keys are disabled so they do not conflict. The base octave moves with the numpad asterisk and divide keys, velocity changes by ten with numpad plus and minus, and holding ALT while changing velocity moves in steps of one instead of ten.

Gamepads, audio routing and a build matrix

Input is not limited to the keyboard. The program uses SDL's game controller system, which should make it work automatically with most gamepads, and on startup it tries to load a game controller database named gamecontrollerdb.txt from the same directory as the config file. If a particular pad does not work out of the box, the README suggests creating custom bindings with a tool such as SDL2 Gamepad Tool. The repository root backs up the client with a CMakeLists.txt, an Android.mk, default.nix, shell.nix and flake.nix, plus an AUDIOGUIDE.md for the audio routing side, and the Makefile offers alternative transport builds, with a libusb target that swaps libserialport for libusb and an rtmidi target that adds the rtmidi library. The project is C with a custom licence in the LICENSE file, releases are v2.2.1 in December 2025, v2.2.2 a few days later and v2.2.3 in January 2026, and the last push was on 2026-09-10.

Editorial conclusion

Adopt m8c if you own a Dirtywave M8 Tracker, you want its screen on a larger monitor or captured into a recording, and you would rather type notes on a full keyboard than on the hardware keypad. Do not adopt it if you are looking for a standalone tracker, since m8c is a front end for the hardware and the Teensy headless firmware, and the display and audio still depend on the device. Verify first that your platform has a build you can use, since Linux on Ubuntu releases before 25.04 needs SDL3 built from source, and check the --list output on Windows 11 where libserialport may not read the USB identifiers, in which case you need the device name from Device Manager and the --dev option.

Frequently asked questions

Official sources

1. Issues
2. laamaa/m8c on GitHub
3. README
4. Releases