Dn-FamiTracker and the maintained fork of 0CC-FamiTracker for NES chiptunes

A fork in a three-step lineage

Dn-FamiTracker is a fork of 0CC-FamiTracker that incorporates numerous fixes and features, and the README is unusually clear about where it sits in the history.

The program lineage lists three ancestors. FamiTracker itself, at famitracker.com, is the original. 0CC-FamiTracker by HertzDevil is the well-known fork that became the de facto tracker for NES and other console music. And nyanpasu64's j0CC-FamiTracker, marked as archived, is an earlier fork of 0CC that Dn-FamiTracker descends from.

The name explains the relationship. The meaning of Dn is Derivative n, which alludes to this fork being the nth derivative of the original FamiTracker program. That is a self-aware piece of naming, and it is the clearest signal in the project about how the author sees the codebase: a derivative that expects to be one of several.

The consequence for an adopter is that the feature set is a superset of a fork of a fork, and the changelog is where you find out what actually changed. The repository has a CHANGELOG.md at the root, and the README points at it and at the release page for more information.

The primary language is C, the licence is a custom one GitHub cannot classify with a pointer to the LICENSE file, and the last push was on 2026-09-23. The recent releases are Dn0.5.3.0 from 2026-05-25, Dn0.5.2.0 from 2025-08-18 and Dn0.5.1.1 from 2025-01-13.

The audience is a chiptune author, and the topic list names the domain precisely: 0cc-famitracker, chiptune, chiptune-tracker, famicom, famitracker, nes, nsf and tracker. The NSF tag in particular points at the export path, which is where a lot of the fork's work went.

What the fork adds over 0CC-FamiTracker

The notable additions list is the most useful part of the readme, and it divides into three groups.

The first is effects. There are new effect columns, Nxx, =xx and Kxx, which is the kind of change that alters how a pattern file reads even for projects that never use them, because the column layout is part of the file format. It also means a tracker that does not understand those columns will silently drop the notes in them, so the version of the tracker you open a project with matters more here than in most projects.

The second is export and format support. There is NSF 2.0 and NSFe export support, and fixed metadata support on NSF 2.0 and NSFe export. The distinction between NSF and NSFe is that NSFe carries extended metadata rather than only the title, artist and copyright fields, so a track exported as NSFe can carry information the older format cannot, and the fix in this fork is about getting that metadata right rather than losing it.

The third is playback and emulation quality. There is DPCM sample bit order reversal, improved FDS, N163 VRC7 and 2A03 emulation, and more accessible DPCM pitch preview and VRC7 patch and envelope editing. The bit order reversal is the kind of bug that makes a sample sound wrong in one player and right in another, so fixing it is a correctness issue rather than a feature.

The export side also has two additions worth singling out. There is complete text import and export, and multitrack per-channel .wav export. Per-channel wav export is the feature that ends the argument about how to get a usable multitrack file out of a tracker, since the usual workaround is to render each channel by hand.

The readme also notes that the Help manual was restored and is now under maintenance at a separate Dn-help repository, which is a common pattern for a fork with a documentation burden too large to keep in the main tree.

Building it: CMake, a Visual Studio solution and a version script

The repository layout tells you that this is a Windows-first project with a cross-platform build path, and that a build system is layered on top of an existing Visual Studio setup.

At the root there is a CMakeLists.txt, a cmake/ directory, a Dn-FamiTracker.sln, a Dn-FamiTracker.vcxproj with its filters file, a Dn-FT_VS_Dependencies.vsconfig, and two example files for CMake user overrides, cmake_user_begin.cmake.example and cmake_user_end.cmake.example. There is a Source/ directory, a res/ directory with Dn-FamiTracker.rc, a Dn-FamiTracker.reg and resource.h, a docs/ directory, a demo/ directory, and the release scripts release.bat and generate-helpmap.bat.

The Python piece is resource_version_update.py, which sits next to version.h and name.h, and that pairing is the clue. The version information that ends up in the executable is generated by a script rather than being hand-edited, which is what keeps the version consistent between the build, the release script and the About box. For a project that cuts releases by hand with a .bat file, that is a meaningful piece of automation.

The example CMake files suggest the intended workflow for a user who needs to adjust the build. The begin and end override files are the conventional CMake pattern for injecting local configuration into an upstream project without editing the upstream CMakeLists.txt, and having them as .example files means the repository ships the extension point without shipping your personal settings.

There are three licence files at the root, LICENSE-GPLv2.txt, LICENSE-GPLv3.txt and LICENSE-MIT-0.txt, plus a LICENSE.md that explains the terms, and the readme states the application is distributed under the GPLv3 or any later version licence.

The demo/ directory contains .dnm files, the tracker's native project format, and their names show what the format holds: a C1 module, a song title and an author, with titles like The Wavetable That Doesn't Wanna Be and Hell or High Water, alongside a RushJet1 directory.

The build pipeline, and the gaps in it

The downloads section is where the project's release process becomes visible, and it is more complicated than a single continuous integration setup.

There is a latest release badge pointing at the GitHub releases page, and a GitHub Actions build artifact workflow, so the current builds come from GitHub Actions. Alongside that there are two legacy AppVeyor badges, one for the automated D.P.C.M. builds under the Gumball2415 project and one for legacy builds under a separate legacy project, and the readme is explicit that they are legacy.

The AppVeyor notice is worth reading because it documents the holes. Due to delayed AppVeyor reintegration, builds for commits dc4c9e86 to 21413603 are not available. Due to delayed AppVeyor branch reconfiguration, builds for commits bc46c86c to a591d154 are not available. And due to less reliability, AppVeyor builds beyond 2c997736 are not available.

So the release history has gaps in it, three ranges of commits where no binary was produced. For a user, the practical effect is that an old commit may simply have no downloadable build, and the readme tells you which ones. It is an unusual thing for a project to document and the fact that it does is a point in its favour.

For anyone building from source instead, the AppVeyor and GitHub Actions situation does not matter much, and the contributing documentation is the place to look. The readme points at a CONTRIBUTING.md file for contributing and compiling.

The primary language is C, which is what you would expect for a tracker that has to talk to chip sound hardware emulation directly and stay responsive while a song plays, and the C plus C++ mixture implied by the vcxproj and the res/ directory is the usual shape for a Windows desktop application of this age.

Where Dn-FamiTracker fits against the alternatives

Three limits are worth stating.

The first is that the original 0CC-FamiTracker is archived, so this fork has inherited a user base rather than competed for one. That has an upside, since the community around a tracker is about song files and shared formats rather than about the binary, and the topic list here shows an active chiptune scene attached to this name. The downside is that compatibility with other tools is now mediated through this fork, and a project file that uses Nxx, =xx or Kxx needs a tracker that knows them.

The second is the platform reality. The build artefacts are Visual Studio and AppVeyor and GitHub Actions on Windows, the version is maintained by a .bat script, and the release pipeline is a .reg file and an .rc resource. There is no claim of Linux or macOS support anywhere in the readme, so if you are on a non-Windows platform, the honest comparison is with a cross-platform tracker rather than with 0CC-FamiTracker.

The third is the size of the feature set relative to the original. This is a fork that has added effect columns, multiple export formats and a revised emulation core to a program that was already large. A user who wants the fastest tracker for editing four-channel NES tunes may find that heavier than they need, and the addon and plugin ecosystem of 0CC is not necessarily portable to it.

The real alternative worth naming is other trackers in the same family rather than a different program. OpenMPT is the other long-lived option for NES and console chiptunes, and it has a different lineage and a different feature emphasis, so the comparison is not simply which fork is newer. What Dn-FamiTracker offers specifically is the 0CC workflow with the effect set and export formats extended, and if that workflow is the one you already use, the fork is the path of least resistance.

Editorial conclusion

Dn-FamiTracker is a good fit for a chiptune author who wants the 0CC-FamiTracker workflow with the newer effect set, working NSF 2.0 export and maintained emulation fixes, since those are the specific things this fork adds over the archived original. It is a poor fit if you need a build you can reproduce on your own machine without following the project's CI, because the project distributes binaries rather than walking you through a source build, and a poor fit if you want a minimal tracker, since this is a fork with a much larger feature set than the original. Before adopting, read the changelog and the release page for the version you plan to use, and check which effect columns your existing projects rely on, since the new Nxx, =xx and Kxx columns change how a pattern file reads even when they are unused.

Frequently asked questions

Official sources

1. Dn-Programming-Core-Management/Dn-FamiTracker on GitHub
2. Issues
3. README
4. Releases