pt2-clone: a ProTracker 2 reimplementation that keeps the Amiga in the room

Accuracy to ProTracker 2.3D is the stated goal, not a side effect

pt2-clone describes itself as aiming to be a highly accurate clone of the classic ProTracker 2.3D software for Amiga, and the project is explicit about how it prioritises. The README says the source code is quite hackish and hardcoded, and that the first priority is to make an accurate clone and not to make flexible and easily modifiable code.

That sentence is the most useful thing in the README for an engineer, because it tells you what kind of codebase to expect and what kind of contributions will be accepted. This is not a library with an API. It is a program that behaves like a specific piece of 1990s software, and the hackishness is a consequence of that goal. Trying to generalise the structure would probably make the accuracy worse.

The project is written in C, which fits the subject matter. A tracker is a pattern editor, a sound chip emulator and a small UI, and the Amiga's Paula chip had particular quirks that a tracker musician learned to write against. The homepage is 16-bits.org, which is the project's own site, and Windows and macOS binary releases are always found there rather than on a package registry.

The audience is specific but not tiny: tracker musicians, demoscene people, anyone who wants to compose MOD and XM style music and hear it through period-correct filtering rather than through a modern sound card.

The licence is BSD-3-Clause, with a LICENSE file at the root and a separate LICENSES.txt, which suggests bundled third party code is accounted for separately from the project's own code.

The Amiga audio path: filters, stereo separation and CIA timing

What separates a tracker clone from a tracker emulator is the audio. pt2-clone adds audio filters and mixer improvements with the stated aim of sounding close to a real Amiga computer, and the key bindings show how much of that model is exposed to the user.

F12 toggles the audio output between Amiga 500 and Amiga 1200. The Amiga 500 mode uses a 4.42kHz 6dB/oct low-pass filter that the README says matches that of a real A500. The README warns that this must not be confused with the LED filter, which it says is a completely different filter, and that distinction matters because a player who applies the wrong one will hear a very different curve.

SHIFT+F12 cycles the stereo separation between centered mono, a custom setting taken from the config file, and Amiga at 100 percent. CTRL+F12 toggles the BPM timing mode between CIA, described as the most commonly used, and vblank, with a warning to only change it if you know what you are doing. ALT+F11 swaps the fake VU meters for real averaged VU meters, and F11 toggles fullscreen.

That last group is telling. Faking the VU meters rather than computing them is what an accurate clone does, because the original hardware did not have real meters either, and the toggle exists for people who want the more useful behaviour instead.

All of these can be made permanent in the config file, which is the mechanism for turning the clone into a setup you do not have to reconfigure each session.

Configuration differs per platform, and the README is specific about it

The config file is protracker.ini, and where it has to live depends on the operating system, which is the kind of detail that trips people up.

For macOS, the README is explicit that protracker.ini has to be in the same directory as the .app itself for the config file to load. For Linux, it should be copied to ~/.config/protracker/ or ~/.protracker/, and if you do that you must make sure to delete any protracker.ini sitting in the same directory as the program executable. The README says an up to date copy can be found in the source tree at /release/other/, or inside the Windows and macOS release zips on the project site.

That warning about the duplicate file is the sort of thing that produces a confusing bug report. A stale config in the executable directory shadows or conflicts with the one in the home directory, and the symptoms are wrong settings rather than an error.

Linux users also get a packaging note: on some distributions a pt2-clone package may be available in the distribution's package repository. That matters for maintenance, because a distribution package means updates arrive on the distribution's schedule rather than the project's.

The repository layout shows how the project is organised for a multi-platform C program. There is a CMakeLists.txt at the root, plus make-linux.sh and make-macos.sh for the two Unix platforms, a vs2026_project directory for the Windows toolchain, a src directory, a release directory for the packaged assets, and a pt_pal_editor directory that appears to be a separate utility for the palette handling the Amiga formats rely on.

Building it: a text file of instructions rather than a documented pipeline

There are no install or build commands in the README. The project points you at a file instead: please read HOW-TO-COMPILE.txt in the repository. That file sits at the root next to the CMakeLists.txt and the two shell scripts for Linux and macOS.

So the honest description of the build process is that it is documented out of tree, in a plain text file, and the repository root gives you the entry points: a CMake build definition, a shell script per Unix platform, and a Visual Studio project directory for Windows.

This matters for anyone evaluating the project. There is no package manager path on Windows or macOS, where you download a binary release from the project site instead. On Linux there may be a distribution package, otherwise you are in the same build-from-source situation. The CMakeLists.txt suggests a CMake-based build, and the presence of a Visual Studio project for a 2026 toolchain suggests the Windows build is maintained as a first-class target rather than a port.

The other top-level files describe the project as a working repository rather than a release-only one. There is a .gitignore, an entitlements file for macOS code signing, and the LICENSES.txt alongside the LICENSE.

The pt_pal_editor directory is worth noting as a separate component. Amiga formats carry a palette in the file, and a standalone tool for working with it is the kind of utility that gets built once and reused. Its presence tells you the project does not only run the tracker but also maintains the file handling around it.

What a clone like this deliberately leaves out

The obvious limitation is stated by the author, and it shapes everything. The code is hackish and hardcoded on purpose, and flexibility was explicitly traded away for accuracy. A developer who wants to embed the tracker's playback in their own application, or to add a new synthesis feature, is working against the grain of the design.

The second limitation is platform coverage of the source. The README only documents the config file location for macOS and Linux and points to the Windows release for binaries, so a developer on an unsupported Unix variant is on their own.

The third is the audio authenticity ceiling. The filters emulate the Amiga models, and the README describes the A500 low-pass as matching a real A500. That is a specific claim about one machine and one filter, and it tells you the emulation is not a general Amiga sound chip emulator with the whole chipset behind it. The keyboard toggles for CIA and vblank timing, the stereo separation settings and the real VU meter option are all narrow, deliberate approximations of specific behaviours rather than a general-purpose chip model.

For a musician that is exactly right. If your goal is a general Amiga audio emulation for games and demoscene productions, this project is aimed at tracker playback and nothing else, and the absence of a broader chip model is a scope decision rather than an omission.

Where a modern tracker sits next to this one

There is a real alternative category here, and the difference is one of purpose rather than feature count. Modern trackers offer a large set of playback features and a far larger instrument format surface, with a modern interface on the platforms they support. What they do not attempt is to sound like an Amiga 500 through a specific filter curve.

So the choice is between a program that reproduces a specific 1990s tracker, and programs that extend the tracker format in new directions. If you write music that needs to sound like it came off a real Amiga, pt2-clone is the tool that gets you there, and the F12 toggle is the reason. If you want advanced effects, arbitrary synthesis or a plugin chain, a general tracker is the tool, and pt2-clone will not grow into one because the author has said so.

Inside the project, the fidelity goal has a second effect. Mod files are a shared format, and a track written for a tracker that emulates Amiga hardware will sound different under a modern player with a different resampler and different sample interpolation. A tracker that preserves the original playback path is what makes a file portable between trackers in the way the original scene intended, and that is a subtle benefit of the clone approach.

The release history shows the project is still moving. Version 1.90 was published on 2026-06-10, 1.91 on 2026-07-05, and 1.92 on 2026-07-24, and the last push to the repository was on 2026-09-17. The repository is not archived.

A small C codebase with a wide licence footprint

The repository is compact. At the root there are a handful of build and metadata files, the source tree, the release directory, the Visual Studio project, the palette editor and the two Unix build scripts. There is no separate documentation directory, so the README plus HOW-TO-COMPILE.txt plus the files in release/other are the documentation.

The BSD-3-Clause licence is a good fit for this kind of project. It is permissive, allows commercial use and modification, and the obligation is to retain the copyright notice and the disclaimer, which for a codebase that people may vendor into their own tools is low friction. The separate LICENSES.txt file at the root indicates that the project also carries third party code whose terms are tracked apart from its own.

The combination of the licence and the accuracy goal is what makes this usable as a base. A commercial game, an installation or a broadcast project that needs period-correct tracker audio can use pt2-clone under BSD terms and adapt it, which is a considerably easier position than the copyleft alternative would give.

Two things to settle before you commit to it. The first is the config file convention, which differs per platform and has a known conflict case between the home directory and the executable directory. The second is the source's readability. The author calls it hackish and hardcoded, which for a clone is a statement of priorities, but it does mean that reading the code to understand a behaviour takes longer than it would in a cleanly factored project, and that is the real cost of the accuracy goal.

Editorial conclusion

pt2-clone fits a musician who writes tracker music, wants the Amiga playback characteristics preserved on a modern desktop, and is comfortable with a program whose stated priority is fidelity rather than modifiability. It does not fit a developer looking for a clean reusable audio library, and the source is explicitly described as hackish and hardcoded, so plan to read rather than extend. Before adopting it, read HOW-TO-COMPILE.txt, compare the build paths on make-linux.sh and make-macos.sh against your own toolchain, and decide early which Amiga model you want the F12 filter to emulate, since that choice changes how your music will sound.

Frequently asked questions

Official sources

1. 8bitbubsy/pt2-clone on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases