OpenMPT and libopenmpt, a tracker editor and its audio rendering library

What this repository is, and the rebasing trap

The first line of the project description says it plainly: this is the official read-only git mirror of the OpenMPT and libopenmpt Subversion repository at source.openmpt.org. Subversion remains the source of truth, and git is a convenience view of it.

That has one consequence that catches people out. The description warns that the repository may occasionally be rebased without further notice when Subversion revision properties, in practice the commit messages, get fixed in recent history after the fact. A rebase rewrites commit identifiers, so a SHA you recorded yesterday can stop existing tomorrow. The advice given is to rebase often if you clone or fork it.

The word read-only matters as well. This is not where contributions land, and the repository carries no GitHub releases either. If you are looking for tagged, downloadable versions of the software, they are not in this mirror, and the README points elsewhere for dependencies and getting started, with doc/libopenmpt/dependencies.md and doc/libopenmpt/gettingstarted.md named as the places to read.

For most users this is a non issue. You consume libopenmpt as a library from a distribution package, and you use OpenMPT as an application. It becomes a real issue the moment you vendor the source into a build pipeline that pins commits.

Two products sharing one codebase: the tracker and the library

The repository holds OpenMPT, described as a free Windows and Wine based tracker, and libopenmpt, a library that renders tracker music to a PCM audio stream. The supported formats listed are MOD, XM, S3M, IT, MPTM and dozens of other legacy formats.

The relationship between them is stated directly in the README: libopenmpt is directly based on OpenMPT, offers the same playback quality and format support, and the two are developed in parallel. So the library is not a reduced reimplementation. It shares the sound engine, which means the library is the interesting half for anyone who wants the exact playback behaviour of a tracker outside a tracker.

The directory layout confirms the split. mptrack holds the tracker application, libopenmpt the library, and openmpt123 the command line tool. Around them sit soundlib for the module handling code, unarchiver for archive extraction, sounddsp for the signal processing, tracklib for the pattern and instrument model, common for shared utilities, and pluginBridge for the plugin host boundary.

The practical consequence for an adopter is that a bug fixed in playback behaviour in the tracker is the same fix in the library, and the release cadence is shared.

Building libopenmpt with the GNU Makefile

The Autotools path is a plain GNU Makefile at the repository root, and it is explicit about its parameters. The build configuration is chosen with CONFIG, which accepts gcc, clang, mingw-w64, emscripten or djgpp, and the default is empty. That emscripten entry is the one to notice for web projects, since it implies a path to compiling the library for a browser runtime.

The toggles that decide what gets built are equally plain:

#  CONFIG=[gcc|clang|mingw-w64|emscripten|djgpp] (default: CONFIG=)
#
#  DYNLINK=1           Dynamically link examples and openmpt123 against libopenmpt
#  SHARED_LIB=1        Build shared library
#  STATIC_LIB=1        Build static library
#  EXAMPLES=1          Build examples
#  OPENMPT123=1        Build openmpt123

Two further switches cover the plugin builds, both off by default:

#  IN_OPENMPT=0        Build in_openmpt (WinAMP 2.x plugin)
#  XMP_OPENMPT=0       Build xmp-openmpt (XMPlay plugin)

The optimisation level is another named variable, with the default set to vectorize:

#  OPTIMIZE=default    vectorize
#           vectorize  -O3
#           speed      -O2
#           size       -Os

The environment variables CC, CXX, LD, AR, CPPFLAGS, CXXFLAGS, CFLAGS, LDFLAGS, LDLIBS and ARFLAGS are all overridable, and a special CXXSTDLIB_PCLIBSPRIVATE variable exists for the C++ standard library needed by static linking, which the Makefile records in the Libs.private field of the libopenmpt.pc file.

That pkg-config detail is worth internalising for packagers. A distribution that links libopenmpt statically needs the private libraries listed, and this variable is how the requirement is communicated to the build system.

Building the OpenMPT tracker under Visual Studio

The tracker application takes a different route, because it is a Windows program built on the Microsoft Foundation Classes. The README states that MFC is required to build OpenMPT, which is the first fact to check before planning a build host.

Supported Visual Studio versions are Visual Studio 2019, and 2022 in Community, Professional and Enterprise editions, plus a Visual Studio 2017 XP targeting toolset for the oldest systems. The solution to open is named by version:

        To compile the project, open `build/vsVERSIONwin7/OpenMPT.sln` (VERSION

with VERSION standing for 2019 or 2022. Other target systems live in the sibling vs2019 and vs2022 folders.

Two constraints here cause real friction. The first is the host system requirement: Windows 8.1 or later on amd64 for VS2019 and VS2017, Windows 10 or later on amd64 for VS2022, or Windows 11 or later on ARM64. The second is a deliberate refusal to support building with a later Visual Studio installation that carries an earlier compiler version. The README explains why: the earlier compiler would still pick up the later C and C++ runtime headers and implementation, which would multiply the configuration matrix that has to be tested.

There is also a manual step. PluginBridge and PluginBridgeLegacy have to be built by hand for architectures other than the one you are building OpenMPT for, because Visual Studio only builds one architecture configuration at a time.

For Windows XP targets, the Visual Studio 2017 XP targeting toolset and the Windows 8.1 SDK are needed, and the SDK is optionally included with Visual Studio 2017.

openmpt123 and the example programs as the first real test

Before wiring libopenmpt into anything, the fastest way to confirm a build works is to render a module with the command line tool. The Makefile builds openmpt123 when OPENMPT123 is set to 1, and the library targets it dynamically by default through DYNLINK. The README defers to doc/libopenmpt/gettingstarted.md for the details of that tool.

The examples directory carries a set of small programs that each demonstrate one way of using the library, and the file names describe the variations: libopenmpt_example_c.c is the plain C example, libopenmpt_example_cxx.cpp the C++ one, and the remaining variants cover reading from memory, writing to a pipe, probing a file, writing to standard output, and using an explicitly unsafe API. That set covers the decisions any adopter has to make anyway: where the bytes come from, where they go, whether the call interface is C or C++, and how much validation the library does on your behalf.

A probe style program is the right first check for a build because it answers a narrow question about a file without committing to a rendering path. If probe works on a module you already know, the decoder and the file handling are sound, and any later problem lies in the playback side.

Where this project is the wrong choice

The clearest case is a Linux or macOS build host that wants the tracker itself. OpenMPT needs MFC and a Visual Studio solution, so the application build is a Windows job, and the Autotools path exists for the library and the command line tool rather than for the editor. Wine is mentioned as a runtime for the tracker, not as a supported build environment.

The second case is a project that pins a git commit. Because the mirror is rebased when Subversion history is corrected, a SHA is not a durable identifier here. Teams that need reproducible builds should take libopenmpt from a distribution package or from a release archive rather than from a commit in this mirror.

The third case is a codebase that needs to write tracker music rather than play it. libopenmpt is a renderer, and the README describes it in those terms, so a synthesis or authoring requirement points at the tracker application and the tracklib code instead.

There is also a licensing subtlety worth reading closely rather than assuming. The project is distributed under the BSD-3-Clause licence, but files under include/ and contrib/ may be subject to other licences, and those folders are not distributed in all source packages, in particular not in the Autotools packages. A downstream packager that redistributes those directories inherits obligations that the top level licence does not describe.

Maintenance state and what an upgrade involves

The last push to the mirror was on 2026-10-09, so the source is receiving changes, and the canonical history remains on Subversion at source.openmpt.org. The project publishes no GitHub releases, which means there is no tag list in this repository to diff against, and the release artefacts live outside the mirror.

The homepage is openmpt.org, and the repository carries an appveyor configuration, a clang-format file, a packageTemplate directory and an installer directory, which together describe a project that produces distributable packages rather than only a source drop.

The upgrade cost depends on which half you consume. For the library, an upgrade means re-reading the changelog for behaviour changes in the module decoder and re-running your own test modules, because playback fidelity is the promise being kept. For the tracker application, an upgrade can mean a new minimum Windows version, a new toolset requirement, or a change in the plugin bridge. The build instructions themselves carry the sharpest version constraint, since the refusal to mix a newer Visual Studio install with an older compiler turns a routine environment upgrade into a toolchain decision.

The BSD-3-Clause licence keeps the legal side simple for commercial use, subject to the separate terms of the include/ and contrib/ folders noted above. That is a licensing observation rather than legal advice.

Editorial conclusion

libopenmpt suits anyone who needs to decode and play tracker music in an application, a game engine or a media tool, and OpenMPT suits people who want to compose in the tracker tradition on Windows. Neither fits a team that needs a stable git commit hash to pin against, because this mirror is rebased when Subversion history is rewritten, and neither fits a build host that is not Windows for the tracker application, since OpenMPT needs MFC and a Visual Studio solution. Verify first that the openmpt123 command line renders a file you already know the expected sound of, that the libopenmpt version you build matches the one your distribution ships, and that the licence files under include/ and contrib/ are acceptable for your packaging, because those folders are not part of the Autotools packages.

Frequently asked questions

Official sources

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