mmmerle

1. The Electrosmith Daisy Guide

The Electrosmith Daisy Seed is a self-contained embedded audio computer on a module roughly the size of a guitar pick: an ARM Cortex-M7 processor running at 480MHz, stereo audio input and output, and a row of exposed pins for potentiometers, switches, and LEDs. Where every circuit in the Effects book manipulates a guitar signal as a continuously varying voltage, the Daisy Seed converts that voltage into numbers, runs code on those numbers, and converts the result back into voltage — a fundamentally different way of building an effect, not just a smaller way of building the same one.

The flip-book mental model for what “digital” actually means

An analog fuzz circuit or op-amp overdrive works directly on the continuous, ever-changing voltage of your guitar signal — at every instant, real, uninterrupted physics is happening to real voltage. A Daisy-based effect instead takes rapid-fire snapshots of that voltage (44,100 or 48,000 times per second, typically), turns each snapshot into a number, and runs a small piece of code on that number before turning it back into voltage on the way out. It’s the same relationship as a movie versus real motion: a flip-book of enough individual still frames, shown fast enough, looks and feels continuous — but underneath, it’s discrete snapshots, not continuous motion. DSP basics for guitarists covers this sampling process in depth; here, the point is just to internalize that a Daisy effect’s “circuit” is code operating on numbers, not components operating on voltage.

What changes between an analog build and a Daisy-based one

This is the practical reason the Daisy Seed is the site’s differentiation focus (see the analog vs digital overview): a single piece of hardware can become an entirely different effect just by loading different code, something no fixed analog circuit can do without a physical rebuild.

libDaisy and DaisySP: the two-layer software framework

Electrosmith maintains two open-source C++ libraries that do the heavy lifting so you don’t write audio drivers or hardware register code yourself:

• libDaisy — the hardware abstraction layer. It handles reading potentiometers and switches, driving LEDs, and — critically — running the audio callback that feeds your code a fresh block of incoming samples and expects a block of outgoing samples back, continuously, in real time.
• DaisySP — the DSP building-block library. It provides ready-made, pre-tested implementations of common effect components — oscillators, filters, delay lines, reverbs — so you assemble an effect from proven building blocks instead of writing every algorithm’s math from scratch.

Together, these two libraries mean writing your first working effect is closer to assembling a small set of function calls than it is to the from-scratch DSP math covered in DSP basics for guitarists and coding effects with C++ — those chapters explain what’s happening inside the building blocks DaisySP already hands you.

Common mistake: treating a Daisy project like a general-purpose microcontroller project

The Daisy Seed can be programmed with the same broad tooling as an Arduino or STM32 board, and it’s tempting to approach it the same way — write some logic, run it, see what happens. Audio processing doesn’t tolerate that looseness: the audio callback has to return a finished block of samples before the next block is needed, on a strict, unforgiving schedule, or the output audibly glitches, clicks, or drops out. Code that would be perfectly fine in a blinking-LED project — a delay loop, a slow debug print, a dynamic memory allocation — can be exactly what breaks real-time audio. This real-time constraint, more than the C++ syntax itself, is the actual learning curve of Daisy development, and it’s covered directly in coding effects with C++.

2. The Hothouse Build

The Hothouse is an open-source DIY pedal platform, designed by Cleveland Music Co., that wraps a complete stompbox around the Electrosmith Daisy Seed: a footswitch, six potentiometers, a toggle switch, status LEDs, and standard 1/4“ jacks, all pre-arranged on a board that accepts a Daisy Seed as its processing core. Where the Electrosmith Daisy Guide covers the Daisy Seed as a general-purpose embedded audio computer, the Hothouse is a specific, guitar-pedal-shaped hardware skeleton built around it — the part of a digital pedal build that would otherwise require designing your own control layout and enclosure from nothing.

The prebuilt-console mental model

Building a custom PC means choosing and wiring every component yourself; buying a console means the hardware is fixed and standardized, so all your effort goes into the software running on it. The Hothouse is the console version of a digital pedal build: its knob count, switch layout, and jack placement are fixed by the platform, which means a builder’s actual work is soldering one well-documented board and then writing code — not designing a control scheme, laying out a PCB, or drilling an enclosure from scratch. That tradeoff — less hardware flexibility, dramatically less hardware design work — is exactly why the Hothouse is this book’s recommended first physical build.

What the Hothouse platform gives you, and what it expects from you

Because the pin mapping is fixed and documented, a knob on a Hothouse-based build always corresponds to a known, named variable in your code — the same knob position that would set a resistor-and-capacitor value in an analog tone control (see potentiometers) instead sets a numeric variable your DSP code reads and acts on.

Assembly is still a real soldering project

Don’t mistake “the hardware layout is fixed” for “there’s no hardware work.” A Hothouse build still requires careful through-hole soldering of the footswitch, pots, jacks, and headers exactly as covered in soldering and tools — cold joints, reversed connectors, or a poorly seated Daisy Seed header cause exactly the same failure modes here as in any analog build. What’s different is what happens after assembly: instead of the pedal’s character being fixed by the components you just soldered, it’s determined entirely by whatever code you flash onto the Daisy Seed afterward.

Common mistake: assuming a finished solder job means a finished pedal

On an analog build, finishing the soldering means the pedal is done — the component values you installed are the sound. On a Hothouse build, finishing the soldering means the hardware is ready, but the pedal still does nothing meaningful until firmware is written and flashed onto the Daisy Seed through its USB connection and the appropriate toolchain. Builders coming from analog projects sometimes underestimate this step, expecting a working pedal the moment the iron goes down — in practice, the software side covered in DSP basics for guitarists and coding effects with C++ is where a Hothouse build actually becomes an effect.

3. DSP Basics for Guitarists

Digital signal processing (DSP) is the practice of representing a signal as a sequence of numbers and manipulating those numbers instead of manipulating voltage directly. On a Daisy-based pedal, your guitar signal is converted into numbers at a fixed rate, run through your code, and converted back into voltage on the way out — every concept in this chapter exists because that conversion has to happen fast, precisely, and without losing the parts of the signal that matter musically.

Sampling rate: how often the signal gets measured

A sample rate of 48,000 Hz (a common Daisy Seed default) means the incoming voltage is measured and turned into a number 48,000 times every second. This connects directly to the flip-book idea introduced in the Electrosmith Daisy Guide: more frames per second means smoother apparent motion, and more samples per second means a more faithful digital reconstruction of the original continuous signal. There’s a hard rule governing exactly how faithful: the Nyquist theorem, which states a sampling rate can only accurately capture frequencies up to half of itself. At 48,000 Hz, the system can faithfully represent frequencies up to 24,000 Hz — comfortably above the roughly 20,000 Hz upper limit of human hearing, which is why that sample rate (and the similar 44,100 Hz used in CD audio) became a practical standard.

Aliasing: what happens when that rule gets broken

Feed a digital system a frequency higher than half its sample rate and it doesn’t just fail to capture that frequency — it misrepresents it as a different, lower, and often dissonant frequency that wasn’t actually present in the original signal. This is called aliasing, and it’s the digital-domain equivalent of a car wheel appearing to spin backward on video at certain speeds: the sampling rate is too slow relative to what’s being sampled, and the result is a false signal, not just a missing one. Effects that generate new high-frequency content internally — distortion and waveshaping effects especially — have to guard against aliasing deliberately, because the distortion process itself can create frequencies above the Nyquist limit even when the original guitar signal didn’t contain any.

Bit depth: how precisely each sample is measured

Where sample rate is how often a measurement happens, bit depth is how precise each individual measurement is. A 16-bit sample can represent 65,536 distinct voltage levels; a 24-bit sample can represent over 16 million. Lower bit depth doesn’t change pitch or timing the way a wrong sample rate does — it introduces quantization noise, an audible noise floor that gets more apparent at low signal levels, similar in effect to (though mechanically different from) hiss in an analog circuit with a poor signal-to-noise ratio.

Buffers: why audio is processed in chunks, not sample by sample

A Daisy-based effect doesn’t process one sample, send it out, then wait for the next one — it processes fixed-size blocks of samples, called buffers, handed to your code all at once by the audio callback (see coding effects with C++). A smaller buffer size means lower latency — less delay between a note being played and the effect’s output being heard — but demands your code finish processing each block faster, since a new one arrives sooner. A larger buffer size gives your code more breathing room per block at the cost of more perceptible latency. Every DSP effect design on the Daisy platform is implicitly working within this buffer-size tradeoff, whether or not it’s stated explicitly.

Translating analog concepts you already know into their digital equivalents

None of the underlying goals change between analog and digital — a low-pass filter still exists to remove high frequencies, clipping still exists to add harmonic distortion — only the mechanism does. That’s why resistors and capacitors and reading schematics are worth understanding even for a purely digital build: the mental models transfer directly, even though the implementation is code instead of components.

Common mistake: assuming “digital” means “perfect” or “free of constraints”

A common misconception is that moving to digital removes the tradeoffs analog builders deal with — noise, filtering artifacts, distortion character. It doesn’t remove them; it relocates them. Aliasing replaces the messier harmonic behavior of an overdriven analog stage, quantization noise replaces thermal and component noise, and buffer-size latency replaces the (much smaller, but real) propagation delay in an analog signal path. Every digital effect design decision covered in coding effects with C++ is, underneath, a tradeoff of exactly this kind — digital DSP isn’t an escape from constraints, it’s a different, code-shaped set of them.

4. Coding Effects with C++

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++

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.