dragonfly-reverb and four free reverbs built on DPF

Four effects, one framework, three platforms

Dragonfly Reverb is a bundle of free audio effects for Linux, MacOS and Windows, and the bundle contains four distinct processors. The repository's plugins/ directory names them, with subdirectories for dragonfly-hall-reverb, dragonfly-room-reverb, dragonfly-plate-reverb and dragonfly-early-reflections. The main page is a collage of the four interfaces, and the site is at michaelwillis.github.io/dragonfly-reverb.

The framing as a bundle rather than a single plugin is the right one, because the four are the same code with different parameters and different algorithm choices. A hall and a room are different convolution spaces, a plate is a different early reflection pattern, and early reflections on their own is the component that gets layered under something else. Buying or finding four separate free plugins means four code bases, four licences and four sets of bugs.

The technology underneath is the DISTRHO Plugin Framework. The Makefile includes dpf/Makefile.base.mk, and the dpf/ directory is a submodule in the tree, with the plugin sources under plugins/ and shared code in common/. The topics list LV2 and VST, and the build system generates the LV2 TTL metadata files, which is how a plugin becomes installable in a Linux desktop's plugin browser.

The audience is a producer or sound designer who wants a reverb, wants it free, and does not want a subscription. The implementation is C++, and the licence is GPL 3.0.

The shared code is freeverb3 and a FFT library

The Makefile's clean target is unusually informative, because it lists exactly what is compiled. It removes object files from common/, and separately from common/freeverb/ and common/kiss_fft/.

That tells you the architecture. The common/ directory holds the code shared between the four plugins, and inside it sit two vendored dependencies, freeverb, which is the Freeverb reverberation algorithm, and kiss_fft, which is a fast Fourier transform library. The early reflections processor needs an FFT to work on the impulse response, and the hall, room and plate processors are built on the Freeverb model, with the difference between them being the parameters and the pre delay and diffusion behaviour that shape the space.

The presence of a vendored copy of freeverb is the important fact for anyone building this, and the README gives the choice explicitly. You can build against the system freeverb3 with SYSTEM_FREEVERB3=true at build time, and if the flag is not set, the bundled freeverb3 is used. The system build also requires libsamplerate, which the bundled path does not, since the vendored copy can be built without a resampling dependency.

That is a real trade-off rather than a preference. Building against the system library means you get the distribution's version, with its fixes and its security updates, and you avoid shipping a stale copy of an algorithm in your plugin. It also means your build now depends on the host system having a freeverb3 development package and on matching its API, which is the kind of coupling that breaks when a distribution updates.

The kiss_fft directory is the same story in miniature, and it is worth knowing that the FFT is vendored rather than pulled from a system package.

Building on Linux or macOS takes two commands

The build instructions for Linux and macOS are as short as they get:

git submodule update --init --recursive
make

The first command is the one that trips people up, because the DPF framework, the freeverb code and the FFT library are submodules, and a plain clone leaves those directories empty. The recursive flag is needed because the submodules have submodules of their own.

The second command runs the top level Makefile, whose default target builds three things in order. The dgl target builds the DPF plugin library with USE_FILE_BROWSER=false, so the plugin binaries do not carry a file browser they do not need. The plugins target then builds each of the four effects in turn. The gen target handles the LV2 metadata, and it is the interesting one, discussed below.

The Linux build dependencies are listed explicitly: libx11-dev, libxext-dev, libxrandr-dev, libgl1-mesa-dev and libjack-jackd2-dev. The X11 and Mesa packages are there for the interface, and JACK is there for the audio, which is the usual choice on Linux for a low latency host. The README also states the runtime requirement plainly: Dragonfly Reverb requires OpenGL 3.0 or newer to show the graphical interface, so on a headless server the plugins will build and run, but their windows will not draw.

The Makefile's clean target is thorough, removing the bin and build directories and the object files from common/, common/freeverb/ and common/kiss_fft/ individually, which is the mark of a project that has been through a few messy incremental build failures.

Cross compiling for Windows from Linux

The README documents a full cross compilation path to Windows from Linux, and it is unusual to find one in a plugin project.

The dependencies are a Wine installation and two MinGW cross compilers:

sudo apt install wine i686-w64-mingw32-gcc i686-w64-mingw32-g++ x86_64-w64-mingw32-gcc x86_64-w64-mingw32-g++

Then a 32 bit build, and a 64 bit build, each preceded by a clean:

make clean
make CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++

make clean
make CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++

The compiler and compiler driver are passed as make variables rather than through a wrapper toolchain file, which keeps the recipe simple and readable, and it matches the fact that the top level Makefile is a thin layer over the DPF base makefile.

Two conditions in the Makefile govern one step of this. CAN_GENERATE_TTL is true when CROSS_COMPILING is not true, and also when EXE_WRAPPER is set, so a wrapped Windows build can still generate the metadata. That is the subject of the next section, and it is the one place where the cross compilation path behaves differently from the native one.

The published downloads confirm that the practice is used in anger. The releases page carries a Linux x86_64 zip, a macOS universal zip, and separate 32 and 64 bit Windows zips.

LV2 metadata generation, and why cross builds skip it

The gen target is the part of the build that is not just compilation, and it is where a plugin becomes installable.

When CAN_GENERATE_TTL is true, the target depends on the plugins and on dpf/utils/lv2_ttl_generator, and it then runs dpf/utils/generate-ttl.sh. The generator is built with a make invocation in its own directory. The output is the LV2 TTL metadata, the Turtle files that describe a plugin's ports and parameters to the host, and without them an LV2 plugin is a binary that no desktop knows how to present.

When the condition is false, the gen target is empty. The condition is false exactly when you are cross compiling and have not set EXE_WRAPPER, and that is a deliberate choice rather than an oversight. The TTL generator is a host tool that has to run natively, and during a Windows cross build there is no native binary to run it, so the step is skipped and the Windows artefact ships without generated metadata.

For an adopter this is the detail to know. A Linux or macOS build produces a package that a desktop's plugin browser can list, with parameters named and described. A cross compiled Windows build gives you the effect binary, and the metadata has to be supplied some other way. If you are packaging for Windows, that is the step to plan for.

The plugin list in the plugins target is also the authoritative inventory of what the bundle contains, since it names the four subdirectories explicitly, and each of those is a separate make invocation and therefore a separate binary.

GPL-3.0, a 2023 tag and a 2026 push

The licence is GPL 3.0, and the README links the GNU GPL version 3 text.

The maintenance picture is the one thing to keep in mind when reading the download links. The releases are 3.2.10 from 2023-04-23, 3.2.8 from 2022-12-28 and 3.2.7 from 2022-09-25, so the newest published build is more than three years old at the time of writing, and every download link in the README points at 3.2.10. The repository itself is not archived and the last push was on 2026-05-21, so work has continued on the branch after the tag.

That means there are two different things in play, a tagged release that most people will install and a moving branch that some people will build. The gap is not necessarily a problem, since an audio effect that works does not stop working, and the pinned DPF and freeverb versions in the submodule make the tagged build reproducible. It does mean that a bug fixed on the branch after April 2023 is not in the binary most people download.

The DPF framework and the Freeverb algorithm are the durable part of this project, and both are long established. The four effects are thin variations on them, with the interface code in common/ and the parameter sets in the plugin directories, so the risk of adopting the bundle is low. The realistic judgement is that this is a finished, working, free collection of reverbs that happens to be maintained more slowly than its documentation suggests.

Editorial conclusion

Adopt Dragonfly Reverb if you want several kinds of reverb, in one bundle, at no cost, and you are willing to install a plugin framework rather than a commercial product. Do not adopt it if you need a preset library, a standalone host application or vendor support, since this is four effect processors with open source interfaces and no product around them. Verify three things first: that your graphics stack provides OpenGL 3.0 or newer, because that is the stated requirement for the interface, that the build finds the system freeverb3 or falls back to the bundled copy as you intend, since the flag changes both the source and the extra dependency, and that the binary you install matches the branch, because the published downloads still point at 3.2.10. The last push was on 2026-05-21 and the newest release is 3.2.10 from 2023-04-23.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. michaelwillis/dragonfly-reverb on GitHub
3. Project website
4. README
5. Releases