Zrythm 2.0 Alpha Tests a Risky Qt Bet for Open Source DAWs

Zrythm 2.0 Alpha puts the open-source digital audio workstation (DAW, music production software for recording, editing and mixing) on a new technical base: C++23, Qt/QML, JUCE and CMake. The May 31 source drop is a test build for feedback, with studio risk still plainly attached, yet it shows why the project is leaving its GTK line for a broader Windows, macOS and Linux future.

Polish can wait in an alpha. Portability debt cannot: audio software lives or dies by plug-ins, driver support and low-latency builds, and a small free-software DAW has to solve those problems while keeping current Linux users from feeling abandoned.

The Alpha Carries a Full Stack Rewrite

The public release marker is modest: an archive in the official Zrythm release directory. Its meaning is bigger. The file list shows zrythm-2.0.0-alpha.1.tar.xz at 26.2 MiB, timestamped May 31 at 03:10, alongside the matching checksum and signature files.

That archive follows an earlier public v2 alpha download stream that the project described as a major rewrite for improved cross-platform support and stability. The same v2 alpha download page warns that the build is for testing only and unsuitable for production work.

For musicians, the version label matters less than the migration path. A DAW session is not a text document. It carries plug-in states, routing, automation curves, tempo maps, recorded audio and dozens of tiny decisions that can turn a late-night idea into a releasable track.

• May 31 – the source archive for alpha.1 appeared in the release directory.
• 26.2 MiB – listed size of the compressed source tarball.
• Three platform builds – the testing page offers GNU/Linux, Windows and macOS downloads for the v2 alpha stream.

The Platform Bet Behind the Toolkit Switch

The old application line was tied to GIMP Toolkit (GTK, a widget toolkit closely associated with GNOME and Linux desktops) and libadwaita. The new work uses Qt/QML, with QML defined by Qt as a declarative language for interface work, and that choice says where the project wants to earn trust next.

Cross-platform DAWs do not get judged only on whether the main window opens. They get judged when a producer plugs in an audio interface, loads a third-party compressor, changes buffer size, records a take, then reopens the same session on another machine. That is where toolkit bugs and packaging seams become user-facing failures.

GTK4’s support on Windows and Mac is poor in my experience.

Zrythm developer Alexandros Theodotou wrote in a support thread on Oct. 31, 2024. In the same reply, he pointed to freezing around save and undo actions, difficult Windows and Mac packaging, and a preference to focus on the Qt port rather than chasing lower-level toolkit problems.

GTK can ship serious applications. For this DAW, the narrower problem is maintenance load: a small audio project with cross-platform goals has less room to debug the desktop stack under the sequencer.

The Stack Shift in One View

The easiest way to read the alpha is as an exchange. The project gives up some near-term polish and compatibility comfort in return for a stack that should be easier to carry across operating systems.

The project had already drawn the line in its 1.0 announcement. In November 2024, Alexandros Theodotou said the GNU/Linux build was production-ready, while Windows and Mac versions were still beta quality; he also said v2 work was moving to C++20 with JUCE and Qt6/QML in the Zrythm v1.0.0 release announcement.

The table also catches the main user decision. If a session matters, stay on the stable line. If the question is whether the rewrite can become a daily driver later, the alpha stream is the visible place to look.

Plug-ins Carry the Highest User Stakes

A DAW without plug-ins is a recorder with a nice timeline. The public source description says the rewritten application is free software written in C++23 using Qt/QML and JUCE, and its feature list includes support for Virtual Studio Technology 3 (VST3, a common Steinberg plug-in format), CLever Audio Plug-in API (CLAP, an open plug-in format), LV2 and AudioUnit plug-ins on the Zrythm source code mirror.

JUCE matters here because it is already a common way to build audio applications and plug-ins in C++. The JUCE framework home page describes support for standalone software on Windows, macOS and Linux, plus several plug-in formats. A framework alone cannot make a host stable. It gives a small team more shared ground with the rest of the audio industry.

CLAP is a smaller but telling signal. Bitwig, the Berlin DAW maker, and u-he, the German plug-in developer, introduced the CLAP audio plug-in standard as an open format for hosts and plug-ins. Native CLAP support in a free-software DAW fits the same posture: reduce avoidable friction where musicians add instruments and effects.

Windows audio is the other hard edge. The Zrythm manual ASIO FAQ says Audio Stream Input/Output (ASIO, Steinberg’s low-latency audio driver technology) can be used only by building the needed pieces yourself, because redistributable builds are constrained by licensing and copyleft obligations. Better Windows support still has to pass that licensing maze.

CMake Points at the Developer Audience

Build systems are boring until they decide who can help. The public source instructions now tell Linux builders to install CMake, Ninja and Qt, then run a CMake configure command and build command. macOS and Windows get their own CMake flows, including Xcode and Visual Studio paths.

The reason this matters is that Qt’s own documentation treats CMake as the normal way to define QML modules; the Qt QML CMake integration guide says the qt_add_qml_module command is the recommended way to define those modules. The project’s build direction now lines up with the toolkit it picked.

CMake also has its own dependency story. The source instructions mention FetchContent, and the CMake FetchContent documentation describes a mechanism for making dependencies available during configuration. That can help contributors reproduce builds, though it also makes dependency hygiene part of the release discipline.

The practical outcome is a wider contributor funnel. A developer who already knows modern C++, Qt and CMake sees a familiar map. A packager also sees the usual tradeoff: more automatic dependency fetching can simplify local builds while raising questions for distributions that prefer system libraries.

Testers Get Access With Hard Caveats

The alpha stream is available because feedback matters before the official release. But the project is blunt about the risk. The testing page says the build is pre-release software, warns against production use, and points users to the issue tracker for bug reports.

• Do not open irreplaceable sessions – the page warns that v2 projects and v1 projects are incompatible.
• Expect missing features – some functions from the stable line may not be present yet.
• Assume crash risk – the project explicitly warns of crashes, data loss and other issues.
• Check platform requirements – GNU/Linux, Windows and macOS each carry listed system requirements for the alpha stream.

Anyone testing should treat the build like a lab machine, not the studio rig before a deadline. The useful reports will likely be mundane: plug-in scan failures, driver glitches, missing keyboard shortcuts, packaging errors, project conversion problems and interface stalls. Those are the bugs that decide whether a rewrite becomes trustworthy.

There is also a payment wrinkle. The stable Zrythm download page presents a mix of free and paid installer options, including bundle and subscription tiers tied to broader release access. Testers should read the current download page carefully before assuming a given build is included in their existing access.

The Trust Gap After the Rewrite

Rewrites are seductive in software because they promise a clean room. They are brutal in music software because users carry old projects, old plug-ins and old habits for years. The v2 work is asking for patience from exactly the users who helped the stable Linux line reach maturity.

That is why the rough interface screenshots matter less than the compatibility warnings. A new theme can be refined. A session boundary cannot be hand-waved by a producer who needs last year’s stem export, or by a hobbyist who wants to reopen a song after a laptop swap.

The counterweight is the scale of the opportunity. If the rewrite makes the application easier to build, test and run across the main desktop operating systems, the payoff is larger than a cleaner UI. It gives an open-source DAW a better chance of meeting musicians where their audio hardware and plug-in libraries already sit.

For now, the alpha should be judged like scaffolding around a building, useful because it reveals the structure before the paint. The useful signal is that the costly part is visible.

If testers turn those rough edges into reproducible bugs, the Qt bet gets a path to a daily driver. If they do not, the rewrite remains a promising branch with no studio trust.