munt: one MT-32 emulation core wrapped in five different front ends

A repository of six related subprojects, not one application

The first thing to understand about munt is that the name refers to a collection rather than a single binary. The repository gathers mt32emu, mt32emu_alsadrv, mt32emu_smf2wav, mt32emu_win32drv, mt32emu_win32drv_setup and mt32emu_qt, plus a DOSBox patch and a FreeBSD port directory. Anyone arriving expecting a downloadable desktop synthesiser will find the interesting code one level down, and anyone wanting to embed an MT-32 emulator in their own program should ignore most of the tree and look at the library directory.

The subprojects are not redundant. Two of them are synthesiser applications (one graphical, one console oriented), one is a kernel-adjacent MIDI interface for Linux, one is a Windows MME driver, one is an offline file converter and one is a set of installer helpers. The project description names the target hardware plainly: pre-GM MIDI modules such as the Roland MT-32, CM-32L, CM-64 and LAPC-I, and it states that the project is in no way endorsed by or affiliated with Roland Corp. That disclaimer matters for anyone planning to ship the code, since the manufacturer names are being used descriptively to describe emulated hardware.

mt32emu is the piece that does the actual synthesis

Everything else in the tree is a consumer of one component: mt32emu, described as a C/C++ library that emulates the Roland MT-32, CM-32L and LAPC-I synthesiser modules. The word approximately is doing real work in that sentence. This is a behavioural and sonic approximation written from scratch in software, not a dump of the original firmware, and the documentation does not claim otherwise.

Because the emulation lives in a library rather than in an application, the audio and MIDI plumbing can differ completely between front ends while the sound stays the same. That is the central architectural bet of the project. A host application can create several synths with separate state and configuration, which means the library is treated as something you instantiate more than once inside a single process rather than as a single global synthesiser.

The other constraint worth noting is that the emulated machines predate General MIDI. Their sound is built around a small palette of partials and a single reverb unit, and anything written for a modern GM sound will sound wrong when routed through it. That is not a defect in the emulation but the reason people reach for it in the first place.

mt32emu_qt is the front end that most users will meet first

The Qt application is the main synthesiser in the collection. It handles realtime synthesis and conversion of recorded Standard MIDI files to WAVE, and it does both through the mt32emu library and the Qt framework. The documented feature list is unusually concrete for a README: multiple simultaneous synths with separate state and configuration, a GUI for configuring synths, managing ROMs and wiring connections to external MIDI ports, MIDI programs and host audio systems, and a display that emulates the MT-32 LCD while showing the internal synth state in realtime.

The audio backend list is the part that matters for adoption. The application is described as cross-platform and is said to support Windows multimedia, PulseAudio, JACK Audio Connection Kit, ALSA, OSS and CoreMIDI. On macOS that means CoreMIDI, which is the piece most users care about, and on Linux the choice ranges from the modern PulseAudio path down to the older OSS route.

Two further conveniences are listed that are less common in free synthesiser hosts. There is a built-in MIDI player for Standard MIDI files, described as optimised for mt32emu, and the application makes it straightforward to record either its MIDI input or its produced audio output. Batch conversion of a whole directory of SMF files to WAV or raw audio is called out as a simplification as well, which is the path most people take when they want an archive of game soundtracks rendered on the target hardware.

The ALSA front end targets small machines and raw MIDI ports

mt32emu_alsadrv sits at the opposite end of the resource spectrum from the Qt application. It comprises a GUI and a console application that use the mt32emu library to provide emulation services over the ALSA MIDI sequencer interface on Linux. The stated reason both a graphical and a console build exist is that the GUI application is mostly obsolete and can be replaced with mt32emu_qt, while mt32emu_alsadrv may still be preferred for systems with limited resources.

That is a rare and specific admission to find in a project README, and it tells you something practical: the console path is not a second-class afterthought, it is the build you want on a small headless box that just needs to appear as an MT-32 to some other program.

The driver also handles a specific integration problem. Applications that rely on raw ALSA MIDI ports can connect through virtual raw MIDI ports, for example ones created with the help of the snd_virmidi kernel module. In other words, the emulation is not visible to every program by default. A client that talks to hardware raw MIDI ports will not automatically see this synth unless a virtual raw port is set up, and that setup step is on the operator.

Offline rendering to WAVE is a separate console tool

mt32emu_smf2wav exists for people who want files rather than a running synthesiser. It converts a pre-recorded Standard MIDI File into a WAVE file using the mt32emu library for audio rendering. The stated equivalence is direct: the output file is said to match a direct recording from a Roland MT-32, CM-32L or LAPC-I module.

This is the subproject with the narrowest surface and the clearest use case. If you are archiving MIDI, scoring a game soundtrack, or comparing a MIDI rendering against the hardware reference, a batch converter that does not need a MIDI port, a GUI or an audio subsystem is exactly the right shape. The Qt application can also do this, but it brings a windowing framework and realtime device handling along with it.

The trade-off is granularity. This tool takes a file and gives back a file. It has no live input, no output port and no session state, so it is not a substitute for the driver or the synthesiser application when the goal is playing.

The Windows driver exposes the emulator to external MIDI programs

On Windows the equivalent of the ALSA bridge is mt32emu_win32drv, an MME driver that creates a MIDI output port and forwards incoming MIDI messages to mt32emu_qt. It also embeds the mt32emu engine and can operate in stand-alone mode if the main Qt application is not available, which is a useful fallback when the user session has no desktop session to host the GUI.

The driver package also carries mt32emu_win32drv_setup, described as helper tools for installation and upgrades of the Windows MME driver. That directory is a reminder that a virtual MIDI driver is a system-level component. Adding or removing one changes how other applications see the MIDI subsystem, and the maintenance cost of the Windows path is therefore higher than for the console tool even though the code volume is small.

The DOSBox-mt32-patch directory is narrower still. It is a patch against the official DOSBox release v.0.74 that demonstrates the possibility of adding an mt32 MIDI device, and it is described as intended for developers and maintainers of customised DOSBox builds. That is not an end user feature, and anyone following it should expect to rebuild DOSBox from source.

Licence terms are unstated and there are no tagged releases

Two facts about the repository shape what you can safely do with it. The first is that no licence identifier appears in the repository record, so the terms under which the code is distributed are not stated there. Anyone intending to embed mt32emu in a commercial product needs to establish the licence position directly before shipping, and this is a legal question rather than a technical one.

The second is that the repository has no GitHub releases, so there is no tagged version to pin a dependency to and no release notes to read for upgrade notes. The only version reference in the project text is the DOSBox patch, which targets the official release v.0.74. Anyone automating a build will be working from a branch, not from a release artefact.

On maintenance, the repository is not archived and the last push was on 2026-10-18, which is recent. That is a statement about the commit record rather than a guarantee of release cadence, since no releases are published from the repository at all.

Editorial conclusion

munt fits musicians and developers who need an MT-32 sound on modern audio stacks, and it is a reasonable reference for anyone studying hardware emulation, but it is a poor fit for anyone who needs a packaged installer or a clearly stated licence. Before adopting it, check the licence terms for yourself, since the repository records no licence identifier, and confirm that your audio backend, either ALSA, JACK, PulseAudio, OSS or CoreMIDI, is covered by the front end you plan to build.

Frequently asked questions

Official sources

1. Issues
2. munt/munt on GitHub
3. Project website
4. README