# Radium is a tracker-style music editor with a graphical canvas

> Radium is a GPL-2.0 licensed C++ music editor inspired by trackers but with fewer limitations, using graphics to show musical data rather than a character grid. Building it needs a C++20 toolchain, Qt, a garbage collector and, for VST support, Steinberg headers that Steinberg no longer ships in its SDK.

**kmatheussen/radium** — A graphical music editor. A next generation tracker.

- Repository: https://github.com/kmatheussen/radium
- Website: http://users.notam02.no/~kjetism/radium/
- Stars: 1,087 · Forks: 53
- Language: C++
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/kmatheussen-radium

## A tracker, but with pictures instead of characters

The introduction is short and defines the whole project. Radium is a free, as in speech, music editor with a novel interface. It's inspired by trackers, but has fewer limitations and uses graphics to show musical data.

That single sentence separates it from the tracker lineage it comes from. A tracker presents music as characters in a grid, a note on a channel and a pattern in a sequence, which is compact and fast to edit but is a text interface with all the limitations of text. Radium keeps the tracker model of patterns, channels and a step sequence, and replaces the character grid with rendered graphics, so notes become blocks, waveforms become pictures, and the editor can show a curve rather than a row of characters.

The stated goal is fewer limitations than a tracker, which is a claim about the interface rather than about the feature set. The tracker approach optimises for a specific workflow, editing a note sequence in dense text, and the constraints come from the text. A graphical editor removes those constraints and adds its own, which is the trade every tracker-adjacent tool makes.

The project is a C++ application, GPL-2.0 licensed, with a COPYING file at the root of the repository, and it is maintained by the team behind notam02.no with the contact addresses k.s.matheussen@notam02.no and info@radium.dog, and a project site at radium.dog.

The licence choice matters for a plugin-hosting editor, because GPL-2.0 is a strong copyleft and a studio that wants to distribute a modified build internally has a different question than one shipping a commercial product.

## The build is a makefile, a shell script and a source tree you read first

The build instructions are the most practical part of the README, and they start with an admonition to look before running.

First, install the dependencies. Second, inspect the file configuration.sh and see if you want to change anything. Third, run the three commands.

```
make packages
BUILDTYPE=RELEASE ./build_linux.sh -j `nproc`
QT_QPA_PLATFORM_PLUGIN_PATH=`$(./find_moc_and_uic_paths.sh qmake) -query QT_INSTALL_PLUGINS` bin/radium
```

The shape of that is unusual and worth understanding. There is a top level Makefile, and the file says at the top, users and packagers, edit build_*.sh instead. So the Makefile is for developers and the build_*.sh scripts are for users, and configuration.sh holds the shared settings. The third command is the odd one, because setting QT_QPA_PLATFORM_PLUGIN_PATH from the output of a helper script that locates moc and uic is how the built binary finds the Qt platform plugin, the shared object that provides the windowing backend. Without it the program starts and exits with a missing plugin error.

The build type is the other decision, and the README explains the three options in detail.

RELEASE is compiled with -O2/-O3 and without various assertions. DEBUG_FAST is the same as DEBUG plus -O2/-O3, described as quite slow but usually acceptable. DEBUG is compiled with -O0/-ggdb plus asan and other sanitizers plus various assertions, and the README warns that it is very slow if your computer is from around 2013 or older, in which case DEBUG_FAST is usually better with -O0 added temporarily in the Makefile for the files needing better debug information.

The Makefile confirms the details. The default BUILDTYPE is DEBUG, the C++ standard is gnu++20, the C standard is gnu99, and the install prefix defaults to /usr/local with bindir and libdir derived from it. The moc and uic paths for Qt 6 are user settings, and PYTHONEXE is resolved by a find_python_path.sh helper for the embedded scripting parts.

## Only release tags are stable, and that warning is unusually direct

There is a section of the README headed, in capitals, IF YOU GOT THE SOURCE FROM GIT, and it contains the single most useful piece of advice for anyone evaluating the project.

WARNING: Only release-tagged commits should be considered stable. If you only do git clone and compile that version of Radium, there's a good chance the program won't compile, or will crash.

The recommended alternative is to download a tagged source archive.

```
wget https://github.com/kmatheussen/radium/archive/<version>.tar.gz
```

And if you do want to work from git, you sometimes have to execute make very_clean after a git pull, since not all dependencies are tracked in the makefile.

That last sentence is the explanation. This is a project where a substantial part of the source tree is generated, and the generated parts are not in version control, so a pull does not update them and the build mixes old generated code with new source. The make very_clean target is the reset.

The repository listing shows how large the generated surface is, with an api/ directory, a common/ directory, a config/ directory, a mixergui/ directory, a midi/ directory, a pluginhost/ directory and an embedded_scheme/ directory, alongside a Makefile, a Makefile.Qt, a Makefile.X11, a Makefile.Qt_old and a Makefile.dummies. The presence of Makefile.dummies and Makefile.Qt_old is the fossil record of a project that has changed its UI toolkit.

The version in the Makefile is 8.1.54, so the internal version scheme is a three part number, and the project publishes no GitHub releases, which means the tags exist but the release artefacts are not attached to them. The last push to master was on 2026-10-13.

## The VST header problem is the classic tracker-era licensing trap

The build dependencies section is short, and one of the entries has a wrinkle that has become a recurring problem across the audio software world.

You need VST headers from Steinberg. The necessary files should be included in the VST Audio Plug-Ins SDK, which you can download from Steinberg's developers page. After downloading the VST SDK, unpack it into your ~/SDKs folder.

And then the update, which is the part that catches people out. Steinberg has removed the VST 2.4 headers from the VST SDK, so you need to download the VST 2.4 headers separately. They can be found on the internet, and the README suggests searching for site:github.com and audioeffectx.h.

The search term is a giveaway, since audioeffectx.h is the header that defines the VST 2.4 plugin interface, and it is a large, notoriously fiddly header that many projects have vendored or reimplemented. The Makefile confirms the expectation, with the include path set as CPLUS_INCLUDE_PATH pointing at the VST2_SDK and VST3_SDK directories inside the SDK folder.

This is the dependency that most affects whether the build works, and it is the one that cannot be fixed with a package manager. A developer working on Radium who needs the VST 2 plugin API has to source a header from a mirror, which is not a comfortable position for a project with a GPL licence and a long history.

The listing also shows the plugin formats the project handles beyond VST, with a ladspa_info/ directory for the LADSPA audio effect format, LV2 include paths in the Makefile pointing into the pluginhost/JuceLibraryCode tree, and a JUCE code tree inside pluginhost, so the project hosts plugins itself rather than depending on a separate host.

## Packaging is done by the distributions, not the project

The distribution story is short and it is worth knowing before you plan an installation.

On Linux, Radium is officially distributed by Arch Linux, and you can find a derivation for NixOS at a git.cfpi-fpsi.eu address.

So the two main declarative Linux package systems are covered, Arch officially and NixOS through a third party derivation, and the README notes that there is an install.sh script and that it works, but that you do not need it to run the program.

The repository listing shows a lot of platform specific material. There is a macosx/ directory, an amiga/ directory, an X11/ directory, a GTK/ directory and an OpenGL/ directory, alongside the Qt/ directory that the Makefile selects by default through the MAKEFILE variable set to Makefile.Qt.

That set of directories is a history. The amiga/ directory is a port to the Amiga, X11/ and GTK/ and OpenGL/ are the older frontend and rendering paths, and Qt/ is the current one. The Makefile.dummies and Makefile.Qt_old files alongside them are the remains of the switches between them.

The build scripts match. There is build_linux.sh, build_linux_common.sh, build_linux_gtk_visual.sh and build_linux_qt_visual.sh, which is the same split in the scripts.

The version 8.1.54 in the Makefile, and a Changelog file at the root rather than a CHANGELOG.md, is consistent with a project that has been developed over a long period in a consistent style. The scripts directory also has an faust_llm_test/ directory and a bench_faust.sh, which indicates work on Faust, the functional audio programming language, and a benchmarking harness for it.

## Where Radium is the wrong choice

The first wrong case is a musician who wants an installer. The project publishes no GitHub releases, the README warns that a git clone may not compile, and the build requires a C++20 toolchain, Qt, a garbage collector, and a VST header set that you may have to source from a mirror. That is a build-from-source project, and for a user who wants to open a DAW and make music, it is the wrong shape of thing.

The second wrong case is a plugin author who needs current VST 3 headers. The README's own note says the VST 2.4 headers have been removed from the Steinberg SDK and have to be found separately, and the search hint in the documentation tells you that the intended solution is a community mirror. A plugin developer who needs to verify their VST 3 implementation against the current SDK is not going to be satisfied by that arrangement.

The third wrong case is a project that needs a maintained codebase. The internal version is 8.1.54, which indicates long development, and the version numbers, the Changelog file, the amiga/ directory and the multiple frontend makefiles all point the same way. The last push was on 2026-10-13, so the work continues, but the project ships source rather than a supported product, and the documentation lives on a separate site rather than in the repository.

The fourth wrong case is a team with a strict licence policy. GPL-2.0 is fine for a hobbyist and for a studio that does not distribute its build, and it is awkward for a company that wants to modify the editor and hand the result to clients. That is a licensing question to settle with your own counsel, but it is a question that has to be asked before the build rather than after.

## How it differs from a tracker

The comparison worth making is with the trackers Radium says it is inspired by, and the difference in approach is the interface.

A tracker is a text editor with a domain specific layout. The pattern editor is a grid of characters, one column per step and one row per channel, and a note is a character or two, an instrument name and a volume. The sequence editor is a list of pattern slots, and the sample editor is a waveform drawn as characters. The power of this is that the entire musical structure fits on one screen as text, and an experienced user edits it at a speed that no graphical editor matches. The limitation is that everything the interface can show is a character, and the domain, the sound, is being described through a notation system rather than looked at.

Radium keeps the structural model and changes the representation. Musical data is shown with graphics, so a note is a block, an envelope is a curve, a waveform is a picture. The stated claim is fewer limitations, and the mechanism is that a graphical canvas is not restricted to what a character can express.

The second difference is the audience. A tracker's interface is learned over years and the learning is a cost that gets amortised over a career. A graphical interface can be more approachable, which is the reason the project exists in a form that reads as trying to lower the barrier, and it also means the editor can show the result while you adjust, which a character grid cannot.

The third difference is the cost of the approach. A tracker is text, so it is fast, portable, diffable, and the whole project state is a text file you can version. A graphical editor is none of those, and it needs a real audio engine, a real GUI toolkit and a plugin host, which is why the build is a compiler project rather than a download, and why it needs VST headers.

## Conclusion

Radium fits an electronic musician or a tracker user who wants a free music editor with a graphical canvas, plugin hosting and an open licence, and who is prepared to build it from source. It does not fit a musician who wants an installer, since the project ships no GitHub releases and warns that only release tagged commits are stable, and it does not fit a plugin author who needs current VST 3 headers from a single download. Before building it, clone a release tarball rather than the branch, because the README warns that a git clone of the current master may not compile, and read configuration.sh first, since the build type and the Qt tool paths are set there.

## FAQ

### How do I build Radium from source?

Install the dependencies, inspect configuration.sh, then run make packages, followed by BUILDTYPE=RELEASE ./build_linux.sh -j `nproc`, and finally launch it with QT_QPA_PLATFORM_PLUGIN_PATH set from the output of find_moc_and_uic_paths.sh. There is an install.sh script that works, but the README says you do not need it to run the program.

### Is the master branch of Radium stable?

No. The README warns in capitals that only release-tagged commits should be considered stable, and that a plain git clone of the current version has a good chance of not compiling or crashing. It recommends downloading a release tarball, and says that if you work from git you sometimes need to run make very_clean after a pull, since not all dependencies are tracked in the makefile.

### Where do I get the VST headers Radium needs?

The VST Audio Plug-Ins SDK from Steinberg's developers page, unpacked into your ~/SDKs folder. However, Steinberg has removed the VST 2.4 headers from the SDK, so those have to be downloaded separately, and the README suggests searching the internet for site:github.com and audioeffectx.h.

### Is Radium available as a package for Linux?

On Linux, Radium is officially distributed by Arch Linux, and a derivation for NixOS is referenced in the README. The project itself publishes no GitHub releases, so the source is built from a release tarball or from a tagged commit.

### What build types does Radium support?

Three, set through the BUILDTYPE variable. RELEASE is compiled with -O2/-O3 and without various assertions, DEBUG_FAST is DEBUG plus -O2/-O3 and is described as quite slow but usually acceptable, and DEBUG uses -O0/-ggdb with asan and other sanitizers plus assertions, which the README warns is very slow on older hardware.

## Sources

- [Issues](https://github.com/kmatheussen/radium/issues)
- [kmatheussen/radium on GitHub](https://github.com/kmatheussen/radium)
- [License: GPL-2.0](https://github.com/kmatheussen/radium/blob/master/LICENSE)
- [Project website](http://users.notam02.no/~kjetism/radium/)
- [README](https://github.com/kmatheussen/radium/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kmatheussen-radium