Coding Effects with C++
A Daisy effect's code lives inside an audio callback — a function that must return a finished block of processed samples before the next block is due, on a strict real-time schedule. This chapter covers that callback pattern, the handful of real-time rules it imposes on ordinary C++, and how AI-assisted coding is already showing up in the Daisy/Hothouse building community.
Every effect running on a Daisy Seed lives inside a single recurring function called the audio callback: libDaisy hands it a block of incoming samples, your code fills in a block of outgoing samples, and it has to finish before the next block is due — continuously, for as long as the pedal is powered on. Ordinary C++ has no built-in concept of a deadline; writing DSP code for the Daisy platform means writing C++ under a small set of real-time rules that don’t apply to most other programming.
The audio callback: the one function everything else serves
Structurally, a Daisy effect’s audio callback looks like a simple loop: for each sample in the incoming buffer, run some math, write the result to the corresponding slot in the outgoing buffer. What makes it different from an ordinary function is timing — at a 48kHz sample rate with a typical small block size, the callback might have only a fraction of a millisecond to process an entire block before the next one arrives. Miss that deadline even once and the result isn’t a slow response, the way a laggy UI update would be — it’s an audible click, glitch, or dropout in the guitar signal itself.
The real-time rules that make audio C++ different from ordinary C++
| Rule | Why it exists |
|---|---|
No dynamic memory allocation inside the callback (new, malloc, or anything that triggers one) |
Allocation timing isn’t guaranteed — it can occasionally take far longer than the callback’s deadline allows |
| No blocking calls (file I/O, printf/debug output, waiting on a lock) | Any operation with unpredictable or unbounded duration can blow the deadline |
| Preallocate everything you’ll need before the callback starts running | Buffers, delay lines, and filter state should be sized and created once, then only read and written inside the callback |
| Keep the math itself bounded and predictable | A loop whose length depends on unpredictable runtime conditions risks an unpredictable callback duration |
None of these are C++ language restrictions — they’re real-time-audio discipline layered on top of ordinary C++, and DaisySP’s built-in building blocks (oscillators, filters, delay lines) are already written to follow them, which is exactly why assembling an effect from DaisySP components is a safer starting point than writing every algorithm’s math from scratch.
From DSP concept to working code: a delay effect as the example
A digital delay effect is a direct implementation of the buffer concept introduced in DSP basics for guitarists: a preallocated array acts as a circular buffer, the incoming sample is written into it, an older sample from further back in the buffer is read out and mixed with the current input, and a position pointer advances and wraps around once it reaches the buffer’s end. Every parameter a user-facing “delay time” or “feedback” knob controls maps to a variable inside this loop — delay time to how far back in the buffer you read from, feedback to how much of the delayed signal gets written back into the buffer alongside the new input. The same pattern, with different per-sample math, is how modulation effects (a delay time that oscillates, per modulation) and distortion effects (a waveshaping function applied per sample, echoing the diode clipping in overdrive and distortion) get built.
AI-assisted coding is already normal in this community, not a novelty
DSP coding for guitar pedals has a real, documented AI-assisted coding culture already forming around it — a February 2026 PedalPCB Community Forum thread titled “vibecoded 7 band eq” describes exactly this: a builder using AI coding assistance to write a working multi-band EQ effect for the Daisy platform. This isn’t a hypothetical future workflow; it’s an already-normalized practice in the exact community this book is written for. The real-time rules above are precisely what make AI-assisted DSP coding both useful and risky in the same breath: an AI assistant can generate working DaisySP-based effect code quickly, but it can just as easily generate code that violates a real-time rule — an allocation or blocking call buried in a helper function — without that mistake being obvious until the pedal glitches in use. Reviewing AI-generated audio code specifically for the rules in the table above is a genuinely useful skill this community is developing in real time, not an edge case.
Common mistake: debugging with tools that themselves break real-time rules
The most common first mistake in Daisy development isn’t a DSP math error — it’s reaching for an ordinary debugging habit, like a printf statement or a breakpoint, to see what a variable is doing inside the audio callback. Both introduce exactly the kind of unpredictable timing the real-time rules above exist to prevent, and both can make an otherwise-correct effect glitch only while you’re trying to debug it, disappearing the moment you remove the debug code. Prefer reading values out to a spare LED, a debug pin, or logging outside the audio callback’s own execution path — debugging technique on the Daisy platform has to respect the same real-time constraints as the effect code itself.