DISTRHO Cardinal: a self-contained VCV Rack plugin for DAWs

The problem Cardinal solves: Rack as a plugin, not a host

VCV Rack is a standalone application. Running it alongside a DAW means routing audio between two programs, and the module library is a separate service that installs modules on demand. Cardinal takes the opposite position. The README describes it as a DPF-based plugin wrapper around VCV Rack that uses the Rack code directly instead of forking it, with the goal of a self-contained, fully free and open-source plugin version of Rack. Everything ships in a single binary: Rack, a set of third-party modules, and a few internal utilities.

The audience follows from that. This is for someone who wants a modular patch living on a track in a session, saved with the project, without a second application in the signal path. The README also states that Cardinal does not load external modules and does not connect to the official Rack library or store, so the module set is fixed at build time. That is a deliberate restriction, not an oversight, and it is the single fact that should decide whether you keep reading.

How the wrapper works and why the plugin comes in four variants

Cardinal is built as a DPF plugin around the Rack sources. The repository layout reflects that: dpf/ holds the plugin framework, plugins/ holds the Cardinal plugin code, src/ holds shared sources such as CardinalCommon.cpp and CardinalPlugin.cpp, and deps/ holds the Rack dependency tree. The root Makefile drives the whole build and pins the version in one place, with comments listing the other files that must be kept in sync, including src/CardinalCommon.cpp, src/CardinalPlugin.cpp and the macOS Info plists.

Because hosts disagree about what counts as an instrument and what counts as an effect, Cardinal ships separate variants of the same plugin rather than one plugin that declares everything. The README says the variants are equivalent in performance and behaviour and differ only in IO and metadata. Main exposes 8 audio inputs and outputs plus 10 CV inputs and outputs, and is unavailable in AU and VST2 because those formats do not support CV ports. Synth has 2 audio outputs, no audio inputs and no CV, and is typed as an instrument. FX has 2 audio inputs and outputs, no CV, and is typed as an effect. Mini is a fourth variant, LV2 and standalone only, with a small hand-picked module selection, 2 audio ports and 5 CV ports.

Mini is the interesting one. Its stated reason to exist is DSP/UI separation, which the README ties to simpler modules. In that mode the DSP can run on a different machine from the UI, controlled over a web browser or a native desktop application. The README points to Cardinal Mini for MOD Audio as a setup already in use.

Installing Cardinal and getting a first patch into a DAW

The README directs users to the release page for official builds and to the Wiki install page for instructions, with additional notes in docs/BUILDING.md. Releases cover Linux, macOS and Windows. Linux builds exist for armhf, arm64, i686, riscv64 and x86_64; macOS is a universal arm64 plus intel build; Windows has 32 and 64 bit builds. Both macOS and Windows builds have an installer, and the README notes that neither is signed, so expect warnings describing an untrusted developer.

On Linux, a typical install from a release archive places the plugin files where the host scans for them. The exact paths are covered on the Wiki install page rather than the README, so check there before copying anything. If you build from source instead, the Makefile exposes PREFIX and DESTDIR and the standard packaging variables:

make
make install PREFIX=/usr/local DESTDIR=/tmp/cardinal-pkg

The first command builds the plugin, Carla, the DGL UI layer, dependencies, plugins and resources; the second stages an install under the given prefix. After installing, rescan plugins in your host. You should see Cardinal listed under the formats your build produced, and the variant names (main, Synth, FX, Mini) tell you which IO layout you are loading.

Inside the plugin, patching works as it does in Rack: add modules from the browser, connect ports with cables, and route the result to the plugin's audio outputs. Because the module set is fixed, the browser shows only bundled modules. Save the host session and the patch travels with it.

What the fixed module set costs you

The README is explicit that Cardinal does not load external modules and does not connect to the official Rack library or store. In practice this means a patch that depends on a module outside the bundled list cannot be reproduced in Cardinal, and there is no mechanism described for adding one short of rebuilding the project. The included list is long, covering collections such as Audible Instruments, Befaco, Bogaudio, ChowDSP and many others, but it is a snapshot tied to a release. Anything published after that snapshot is absent until the next build.

The release cadence supports that reading. Version 26.02 arrived on 2026-02-28, 26.01 on 2026-01-31, and 25.06 on 2025-06-22, so module additions reach users at release boundaries rather than continuously. The last push to the repository was on 2026-07-28, which is under two months before today, so the project is not dormant, but the shipped module set still moves at release pace.

Other limits are stated plainly. CLAP support is a work-in-progress tracked as DPF issue 383, and the main variant is not available in CLAP yet. VST3 plugin hosting inside Carla or Ildaeil modules mostly works but is called experimental. Windows 32 bit builds still have problematic modules, referencing issue 80. None of these are hidden; they are listed under the current status heading, which is more candour than most plugin READMEs offer.

Cardinal versus running VCV Rack itself

The obvious alternative is VCV Rack, which Cardinal is based on. The difference is architectural. Rack runs as its own application and its library installs modules from a store; Cardinal runs as a plugin inside your host and carries its modules in the binary. If you want the newest module the moment it is published, or you maintain patches that mix many third-party collections, Rack is the tool that matches that workflow. If you want a self-contained patch that opens with your DAW session and never asks the network for anything, Cardinal is the one designed for it.

There is a second difference worth naming. Cardinal removes all VCV branding, which the README says was done to the best of the project's knowledge to avoid trademark issues. That is a legal-posture decision as much as an aesthetic one, and it is why the plugin does not present itself as Rack in a host's plugin list.

Licence and the cost of keeping up

Cardinal is GPL-3.0, and the Makefile headers carry SPDX-License-Identifier: GPL-3.0-or-later. For anyone embedding this in a commercial product, that is the constraint to examine first, because the bundled third-party modules come from many separate projects and the README does not enumerate their licences. Verify each module's terms before redistributing a build; this is a factual check on the sources, not legal advice.

Upgrade cost is low if you use official builds: download a new release and reinstall. It is higher if you build from source, because the tree is a set of git submodules (the repository has a .gitmodules file) plus a patches/ directory applied to dependencies. Moving between releases means updating submodules and rechecking those patches. The Makefile's version comment listing every file that hardcodes the version is a fair warning that a version bump touches more than one place.

Editorial conclusion

Adopt Cardinal if you want a modular patch inside a DAW session and cannot accept a plugin that reaches out to an external module store, or if you need the LV2-only Mini variant for DSP and UI separation on an embedded host. Do not adopt it if your patches depend on modules outside the bundled list, or if you rely on VST3 plugin hosting, which the README calls experimental. Before installing, check the release assets for your architecture and plugin format, and read the Wiki install page, because the macOS and Windows builds are unsigned and the README says to expect untrusted-developer warnings.

Frequently asked questions

Official sources

1. DISTRHO/Cardinal on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases