airwin2rack: the Airwindows effects in one registry, Rack module and DAW plugin

One effect suite, three ways to consume it

airwin2rack takes the Airwindows collection and presents it in three shapes. The first is a static library with a uniform registry and access pattern, intended to be used as a submodule so you can expose the Airwindows inside your own code. The second is a module for VCV Rack, published in the Rack library and also as a Rack nightly build, with its own manual in doc/manual.md. The third is a DAW plugin built for CLAP, VST3, AU and LV2 as well as standalone, with a separate manual in doc/manualdaw.md. The project states plainly that if you are a user, those links are everything you need, and if you are a developer, read on. That split is the whole architecture, and it means the same DSP reaches a Rack user, a DAW user and a code base through one registry rather than three independent ports.

The registry target is the part developers actually link

The static library version is the piece with the least ceremony. The target airwin-registry builds a static library containing all of the Airwindows under a uniform api, and linking that target is enough for it to populate the data structures automatically, so AirwinRegistry.h does what you would expect from it: it hands you a map for creating airwin2rackbase operator objects. Documentation of the api is still a todo, which is the honest state of it. The practical consequence is that a developer can vendor the target as a submodule, include the header, and get the operator map populated without hand-maintaining a list of effects. The repository layout matches that division, with src/ holding the portable core, src-juce/ the JUCE plugin sources and src-rack/ the Rack plugin sources.

Building the JUCE plugin with two cmake commands

The DAW plugin is built with JUCE, and the project states that with git, a compiler and cmake working, the build is easy. On unix you are pointed at a list of packages or their equivalents, which comes from the project's own build workflow. The clone and build sequence is short.

cmake -Bignore/daw-plugin -DBUILD_JUCE_PLUGIN=TRUE -DCMAKE_BUILD_TYPE=Release
cmake --build ignore/daw-plugin --target awcons-products

The first cmake call configures a build directory called ignore/daw-plugin with the JUCE plugin enabled and a Release build type. The second builds the awcons-products target from it. The naming is a little confusing, since ignore is the build output directory rather than something to ignore, but the effect is that a distributable plugin set lands there. The project states that the nightly builds cover 64 bit ubuntu x64, mac universal and win x64, that it should build anywhere, and that it is known to build on linux ARM.

Rack uses qno's cmake SDK and needs a clean rebuild

The VCV Rack module is built with qno's cmake SDK, and the project notes that this means the makefile works like any other Rack project. The Makefile at the repository root shows how thin the wrapper is. RACK_DIR defaults to ../.. and pulls in the SDK's arch.mk, then the plugin target runs cmake with -DRACK_SDK_DIR pointing at that directory, -DBUILD_FOR_RACK_ONLY=TRUE, -DBUILD_RACK_PLUGIN=TRUE and a Release build type, installs into dep/cmake-build/dist and copies the result into the repository root. The plugin file extension follows the platform, so plugin.so on Linux, plugin.dll on Windows and plugin.dylib on macOS, with separate x86_64 and arm64 handling on Apple silicon. One instruction matters for anyone pulling changes: the project says to run both the clean and cleandep targets for a full rebuild, and the Makefile exposes exactly those targets.

Refreshing the Airwindows sub-library is a scripted step

The Airwindows effects themselves live in a sub-library, so keeping them current is a separate operation from building the plugin. The documented procedure starts by pulling the latest Airwindows plugins with a script in the repository.

./scripts/updateToLatest.sh

After that comes a test build of the Rack plugin, which is the sequence the project lists for a full rebuild of the dependencies and the install.

RACK_DIR=(path-to-sdk) make -j cleandep
RACK_DIR=(path-to-sdk) make -j clean
RACK_DIR=(path-to-sdk) make -j install

The path-to-sdk placeholder has to be replaced with your own VCV Rack SDK location, and the parallel flag lets the compile use every core. The final step is committing the source libraries and the infile and pushing to GitHub. Note that the numbering in the project text skips a step two, so treat the list as three actions rather than four.

The licence answer is more nuanced than MIT

The README has a section on licensing that is worth reading carefully before you plan a release. Airwindows is MIT licensed and the source here is also MIT, with all code and content in src, in libs/airwindows and in res/awdoc freely available and fine to use in closed source code. The practical consequence is that you can link the airwin-registry cmake target, use AirwinRegistry.h and do what you want. But a combined work with JUCE and the VST3 SDK, or with the VCV Rack SDK, brings in GPL3 and GPL3+ dependencies, so even though src-juce and src-rack are MIT licensed, building a distributable product with those sources may result in your including GPL3 assets. The project answers the closed source question directly: use AirwinRegistry.h and its dependencies, the airwin-registry cmake target, the documentation in res/awdoc, the top level CMakeLists.txt and everything in src. If your situation is still unclear, the README says to open an issue and explain it.

Assets and fonts carry their own terms

Two extra assets sit outside the code. The clipper Airwindows graphic is freely distributed by Airwindows, so you can reuse it without chasing a permission. The Jakarta and Fira Mono fonts are both openSIL, licensed under the SIL Open Font License, with the Jakarta Sans project linked from the README. That matters for a plugin that ships a default interface, because the font choice is baked into the look of the Rack module and the standalone application. The screenshots in the project overview show the Airwindows module in dark mode and the Airwindows CLAP running inside Bitwig Studio, which is a useful check that the plugin loads in a host before you invest in a build pipeline of your own.

What the release tags do and do not tell you

The repository publishes three distinct release streams, and they are dated quite differently. The Nightly tag for the Rack build is dated 2023-01-16, the DAWPlugin tag is dated 2024-04-23, and the named release v2.12.0 is dated 2024-07-09. The last push to the repository was on 2026-10-18, so the working tree is being worked on well after those tags, which means the source on main is newer than any published artifact you can download. If you are pinning to a release rather than building from source, that gap is worth knowing about, since a bug fixed after v2.12.0 will not be in the plugin a user installs from the release page. The top level also carries a .clang-format file and a plugin.json, the latter being the manifest the Rack ecosystem uses to describe the module.

Editorial conclusion

airwin2rack fits a plugin developer who wants the Airwindows DSP without shipping the standalone applications, since linking the airwin-registry target and using AirwinRegistry.h gives you the whole set under one access pattern, and it fits VCV Rack or DAW users who would rather install one plugin than many. It does not fit a closed source DAW plugin team, because the README states that a combined work with the JUCE and VST3 SDKs or the VCV Rack SDK pulls in GPL3 and GPL3+ dependencies, so shipping src-juce or src-rack code may mean including GPL3 assets. Before you commit, read the licensing note end to end, check that the airwin-registry target and AirwinRegistry.h cover the effect you actually want, and run both the clean and cleandep targets after pulling, as the project asks, so you are not building against stale dependencies.

Frequently asked questions

Official sources

1. baconpaul/airwin2rack on GitHub
2. Issues
3. License: MIT
4. README
5. Releases