DaisySP: a modular C++ DSP library that runs on hardware, plug-ins and phones

One module set, four very different hosts

DaisySP is a DSP library in C++ that provides modular components for creating audio software across various contexts, and the interesting claim of the README is about where the same code ends up. The listed applications are embedded hardware on the Daisy Audio Platform, audio plug-ins in the VST and AU formats with a JUCE example, mobile apps on iOS and Android, and VCV Rack modules. That last combination is what makes the library worth looking at. A synthesis library written for a plugin host usually assumes a sample rate, a block size and a callback that can allocate; one written for a microcontroller assumes something else again. DaisySP does not present itself as either. It presents itself as a collection of processing components, and the host is somebody else's problem. The upstream project is Electro Smith, the hardware company behind the Daisy platform, and the repository links, badges and clone URL in the README all point at the electro-smith organisation, which is a useful detail if you are looking for the canonical source.

The Makefile is the real catalogue

The README summarises the feature areas, but the Makefile is the authoritative list because it is what actually gets compiled, and the two do not match exactly. The Makefile enumerates module directories with their module names. Control holds adenv, adsr and phasor. Drums holds analogbassdrum, analogsnaredrum, hihat, synthbassdrum and synthsnaredrum. Dynamics has crossfade and limiter. Effects has autowah, chorus, decimator, flanger, overdrive, phaser, sampleratereducer, tremolo and wavefolder. Filters has ladder, svf and soap. Noise has clockednoise, grainlet and particle. PhysicalModeling has drip, KarplusString, modalvoice, resonator and stringvoice. Sampling has granularplayer. Synthesis has fm2, formantosc, oscillator, oscillatorbank, variablesawosc, variableshapeosc, vosim and zoscillator. Utility has dcblock and metro. The README's feature list mentions things you will not find in that enumeration, such as FIR filters and one pole lowpass and highpass filters, and the reason is in a comment at the top of the Makefile: header only modules are listed commented out below the others. So a module can exist, be usable, and still be absent from the compiled module list.

The API is one Process call per sample

The code example in the README shows the convention, and it is the part you should copy before you copy anything else. Each module is a small object with a `Process` method, and the objects are declared as static instances at file scope, so their state persists between calls without anything being allocated in the loop. The example wires a phasor style oscillator into a lowpass filter and writes the result into the output buffer, one sample per iteration of the loop, with a `SetFrequency` call whenever the cutoff changes.

#include "daisysp.h"

static daisysp::OnePole flt;
static daisysp::Oscillator osc, lfo;
float saw, freq, output;

for(size_t i = 0; i < size; i++)
{
  freq = lfo.Process();
  saw = osc.Process();

  flt.SetFrequency(freq);
  output = flt.Process(saw);

  out[i] = output;
}

Two conventions follow from that. The first is that a module is cheap to construct and holds only a little state, so the static instance pattern is the intended usage rather than an optimisation someone thought of later. The second is that everything is sample based, which is what lets the same code run in a plug-in and at a different rate on embedded hardware. The header include is the single include, `daisysp.h`, so the whole library is reachable from one line.

Building it: a Makefile, a CMake project and a Visual Studio solution

The getting started section is three commands. You clone the repository, change into the directory, and run `make`, which builds the library, and then you make some noise with the example programs that live in the separate DaisyExamples repository.

git clone https://github.com/electro-smith/DaisySP
cd DaisySP
make

The repository root shows the other build paths. There is a `Makefile` whose target is `libdaisysp`, a `CMakeLists.txt` for CMake based projects, and `daisysp.sln` for Visual Studio, so a Windows developer is not forced through the Make. A `Doxyfile` sits next to them, and the documentation is published at daisy.audio/software rather than hosted in the repository, which is where the contributing guide sends people who want to proofread it. The root also contains `doc/`, `tests/`, `util/`, `resources/`, `ci/` and a `vs/` directory, so tests and tooling are part of the tree rather than a separate repository. Continuous integration is visible in the badges: separate workflows for the build, for code style and for the documentation, which tells you the project treats formatting and generated docs as things that must keep passing, not as afterthoughts. The Makefile also notes that header only modules are excluded from the compiled list, so a build that expects a binary for every module will not find one.

MIT, with a licence file and an LGPL entry beside it

The licence story is straightforward but worth reading carefully, because the repository root carries more than one thing that looks like a licence. The README has a License section stating that DaisySP uses the MIT licence, that it can be used in both closed source and commercial projects, and that it does not provide a warranty of any kind, with a pointer to the LICENSE file in the root directory. The badge at the top points at the MIT text as well. Alongside the LICENSE file there is a top level entry named DaisySP-LGPL, which is a signal that not everything in the tree necessarily carries the same terms, and the contributing section reinforces that by asking contributors to port existing DSP modules from other open source projects and specifying MIT for those ports. The practical reading is that the framework is permissively licensed and friendly to commercial use, while individual ported modules keep whatever obligations their origin carries, including attribution. That is a normal arrangement for a synthesis library, and it is the sort of detail you check in the file headers rather than in the README. The MIT terms also mean you get the code without any warranty, which is worth remembering if you are shipping audio products.

A module list with conspicuous absences, and a release history that stopped

Two limitations are visible in what the repository documents. The first is the shape of the catalogue. There is no reverb and no delay in the compiled module list, and a drum machine, some filters and a granular player do not add up to an instrument. Delay and reverb are exactly the two effects a synthesiser user looks for first, so you will be sourcing them elsewhere or writing them yourself, and the same applies to any host specific work: a VCV Rack module and a VST plug-in both need the surrounding scaffolding that DaisySP deliberately does not provide. The second limitation is the release history. The tagged releases are v0.0.1 in February 2021, v0.0.2 in December 2023, and V1.0.0 in January 2024, while the last push was on 2026-09-28. So the source is being worked on, but there has been no release in more than two years, and the tag naming switches between a capital V and a lowercase v. For a library that people vendor into hardware projects, that gap between the tree and the tag is the thing to check, because your build might reasonably be expected to track the released version rather than a moving branch.

Compared with a full audio framework

The realistic alternative is not another DSP library but an audio framework that ships its own synthesis code, such as the JUCE ecosystem that the README itself points to for plug-in examples. The difference in approach is what each one owns. A framework gives you the host integration, the audio callback plumbing, the parameter handling, the file IO and often a set of built in processors, and it asks you to build your instrument inside its conventions. DaisySP owns none of that and supplies only the signal processing primitives, which means you keep whatever host layer you already like, including a JUCE plug-in or a bare metal embedded target, and you take on the work of wiring modules together, of handling parameters, and of whatever else your host needs. For a hardware product that is the right shape, because the firmware around the DSP is already bespoke. For a plug-in team that wants to ship quickly, the framework path is shorter, and DaisySP becomes a source of processor code to call rather than the architecture of the product.

Editorial conclusion

Adopt DaisySP if you are writing real time audio and want readable, tested-by-usage building blocks instead of a large synthesis framework, and if your target is one of the contexts it was built for, the Daisy embedded platform, a plug-in, a mobile app or a VCV Rack module. Do not adopt it expecting a complete instrument, since there is no reverb or delay module in the list and you will be assembling effects chains yourself. Before you start, check which modules are header only, because the Makefile lists them commented out separately from the compiled ones, and confirm the build path you need, `make` for the library, CMakeLists for a CMake project and `daisysp.sln` for Visual Studio. The licence is MIT and covers closed source and commercial use without warranty, the newest release tag is V1.0.0 from 2024-01-08, and the last push was on 2026-09-28.

Frequently asked questions

Official sources

1. daisyaudio/DaisySP on GitHub
2. Issues
3. Project website
4. README
5. Releases