Dplug: commercial audio plug-ins written in D across seven formats

One D codebase, seven plug-in formats

Dplug is a framework for building audio plug-ins in the D programming language, and the pitch in the README is that you can create professional audio plug-ins with minimal headaches and maintenance cost. The primary language of the repository is D.

The scope is unusually wide for a plug-in framework. The README states the same features apply across the formats:

  - Same features for `VST2` / `VST3` / `AUv2` / `AAX` / `LV2` / `CLAP` / `FLP` plug-in formats.
  - Same features for desktop OS: Windows / macOS / Linux.
  - Easy SIMD compatible with both `x86`, `x86_64`, and `arm64` with same codebase.

That is the central claim, and it is the reason to look at the project. A plug-in framework that forces you into C++ and a separate build system for each format multiplies the maintenance cost of every bug fix. Dplug aims at the opposite, and the way it gets there is by insisting that you never touch the platform toolchains yourself. The README lists what you avoid:

  - No interaction needed with `Xcode`, `CMake`, `C++`, `Obj-C` or `MSVC`.
  - Lovable D language, suitable from prototyping to production.

The D language itself is the bet underneath. The README argues for it in terms of learnability, build times, and morale rather than raw speed, and it argues that the SIMD story is easy across x86, x86_64, and arm64 with the same codebase, which matters now that Apple Silicon is a first class desktop target.

The framework covers more than the plug-in shell. There is a DSP library, an FFT directory, IIR filtering, a fast 2D software rasterizer in dplug:canvas with canvasity as an alternative, a flat widget set, PBR widgets for skeuomorphic interfaces, Wren scripting for UI authoring, window handling with an x11 directory for Linux, and support for PNG, JPEG, QOI, and a custom QOIX codec.

The format and platform grid has holes you have to plan around

The README includes a grid crossing seven formats against four platform targets, and reading it is the fastest way to understand the framework's limits.

VST2, VST3, LV2, and CLAP are the fully covered formats, with support for macOS on both arm64 and x86-64, Windows on x86-64, and Linux on x86-64. AUv2 is macOS only, which is unsurprising given that it is Apple's format. AAX covers macOS and Windows but not Linux. FLP, the FL Studio format, is Windows only and marked as unsupported on both macOS architectures.

The practical consequence is that format support and platform support are not the same axis. If your product needs to be in AAX, you are targeting macOS and Windows and nothing else, and the Linux build of your plug-in is not an option even though the Dplug code for it would be identical. The same applies to FLP, which exists for one platform and one host.

Two more entries in the README's list of strengths tell you where the unusual work has been done. There is a fast 2D software rasterizer described as having no OpenGL headaches, and optional physically based rendering for what the README calls video game like skeuomorphism with small RAM and disk usage. Those are the parts of the stack that a graphics API would normally handle, and Dplug replaces them with its own implementations. PBR rendering for interfaces is a genuinely odd choice, and a fair question is whether it is worth the maintenance, but it is what lets the interface look the same on every platform.

For a plug-in that needs a very specific look, that consistency is the argument for it.

DUB as the build system, and the Dplug example projects

Dependency management is handled by DUB, the standard package manager for D, and the README says you build any Dplug tool with the dub command. That single point matters more than it might look. A plug-in framework that removes Xcode, CMake, and MSVC from your workflow is only useful if there is exactly one command that produces the artifact, and DUB is what fills that role here.

The repository layout shows how the framework is decomposed. The root holds dub.json, package.d, an ARCHITECTURE.md, a plugin-schema.json, and directories for the pieces: core, dsp, audio, fft, iir, math, formats, host, gui, graphics, canvas, flatwidgets, pbrwidgets, window, client, wren, and the platform directories macos and x11.

Under examples/ there is a set of projects that read as a learning path rather than a demo dump. The list includes arpejoe, clipit, distort, faust-example, ms-encode, poly-alias-synth, simple-mono-synth, and template. A template project is the sign of a framework that expects to be copied, and the Faust example shows a route into Dplug from an existing DSP language.

The README also documents automated macOS and Windows installers, signing, and notarization. For a commercial plug-in that has to ship signed and notarized to pass macOS Gatekeeper, having that in the framework rather than in your own release scripts is a large part of the maintenance saving the project advertises. A DAW support list is kept in the wiki.

The wiki is where the Getting Started guide lives, along with the release notes, the host support list, and the separate guides for VST2, VST3, and AAX.

SemVer as a promise about user sessions, not just about code

The governance section is the most distinctive part of the README, and it explains what kind of project this is.

The key concept is stated plainly: Dplug uses SemVer, and if you stay on the same Dplug major version tag, for example a constraint written as "~>13.0", your plug-in will not break and, more importantly, your user sessions will not break either. That last clause is unusual. It is a compatibility statement about the saved state a host writes into a user preset or session, which is a much harder promise to keep than source level compatibility, because the framework controls the serialisation format of your plug-in's state.

The mechanism supporting the promise is that breaking changes only happen for major tags. All breaking changes are documented in the changelog, and the project issues major SemVer tags for breaking changes. If you cannot accept breaking changes, you pin Dplug to a major version in your dub.json.

The self description is candid. Dplug's goal is to support existing products and build commercial companies around them, it is a part-time operation from people who release commercial plug-ins for a living, and stability and a relatively bug-free build are deemed more important than implementing every possible feature. The README goes further and says enhancements often get postponed in favour of product development, and asks for patience.

There is a trade-off in that, and it is deliberate. You will not get every feature first, and the codebase moves at the pace of a handful of people with day jobs. In exchange, the major version contract is something you can put in a commercial release plan, which is exactly what a plug-in vendor buying a framework needs.

The list of plug-ins made with Dplug is the evidence for that claim, and it is a commercial one. It includes Convergence, Couture, Entropy 3, EpicPRESS, Faradelay, Graillon, Inner Pitch, Lens, M4 Multiband Compressor, Nu:Cat, Panagement, Renegate, Tarabia MK II, and Yamatube Pro, from vendors such as Cut Through Recordings, Auburn Sounds, SMAOLAB, and Kitsunebi Games.

The Steinberg SDK and licence are hard gates, not paperwork

Two legal facts sit inside the technical setup, and both can stop a project before any code is written.

The first is the VST3 SDK. The README is explicit: if you do not have the VST3 SDK, you cannot make VST3 plug-ins with Dplug, and the SDK is to be found on the Steinberg developer site. So the framework does not ship the headers you need for the format it advertises most prominently.

The second is licensing. The README states that without a licensing agreement with Steinberg you cannot distribute VST2 or VST3 plug-ins. The same sentence covers both the older VST2 format and the current one, which is a fair warning for anyone who assumed VST2 was free to ship now that it is a legacy format.

A third constraint comes from the format list itself. AAX is Adobe's format, and the README points to a separate Dplug AAX Guide, alongside the Dplug VST2 Guide and the Dplug VST3 Guide. Those three guides exist because each format has its own rules about what the wrapper does for you, so the framework can automate the repetitive parts without hiding the parts you must still get right for a given host.

None of this is legal advice, and the README does not attempt to summarise the agreement terms. The point for a technical decision maker is that the SDK download and the licence negotiation are the long lead items in the schedule, and both sit outside the framework.

Per sub-package licences and a repository with no GitHub releases

The licensing story inside the repository is not one licence. The README says Dplug has many different licenses depending on the sub-package you need, asks you to check individual source files for licence information, and asks you to respect the individual licences when releasing a plug-in.

That is an unusual arrangement for a framework, and it has a direct consequence for you. The top level repository is classified as a custom licence that GitHub cannot categorise, with a LICENSE.txt file at the root, but the terms that actually apply to the code you link into your product are per package. The DSP library, the GUI widgets, the graphics stack, and the format wrappers may each carry different terms, and a plug-in that bundles them inherits all of them. A company shipping a commercial plug-in has to do that inventory before release, which is why the README tells you to do your homework.

The repository also has no GitHub releases. The release history lives in the wiki, as the Dplug Release Notes, and the wiki changelog is where the documented breaking changes are collected. So the version tags referenced by the SemVer promise exist in the repository, but the readable release record is on the wiki rather than on the releases page.

The last push to the master branch was on 2026-10-10, and the project is not archived. The main development branch is moving, the wiki carries the release notes and the per format guides, and the project also runs a Discord community, with a second Discord link for people working on Dplug plug-ins.

Editorial conclusion

Dplug fits a team that wants to write DSP in D and ship one plug-in to every major host on Windows, macOS, and Linux without maintaining C++ bindings, a build system, and a signing pipeline for each platform. It is the wrong tool if you need the newest format on every platform, since AAX has no Linux target, AUv2 exists only on macOS, and FLP is Windows only, or if you need VST2 or VST3 without a Steinberg licensing agreement. Before starting, obtain the VST3 SDK from Steinberg, read the Dplug VST2, VST3, and AAX guides for the per format rules, and check the individual source file licences, since Dplug uses different licences per sub-package and the repository is classified as a custom licence GitHub cannot categorise.

Frequently asked questions

Official sources

1. AuburnSounds/Dplug on GitHub
2. Issues
3. Project website
4. README