DEV Community: Lluis Estape

Your LFO runs at the buffer size: auditing the control rate of my own synth

Lluis Estape — Wed, 23 Sep 2026 09:33:28 +0000

A follow-up audit of SYNTH/1, my JUCE wavetable synth. The oscillator has been measured, rewritten and measured again. Everything that modulates it had never been measured once. I pointed a meter at five of those paths and all five were wrong, one of them by a factor of thirteen.

In the plugin post I wrote about finding that my oscillator had been aliasing over most of the keyboard for a year, and about the rewrite that fixed it: mip-mapped tables, cubic Hermite interpolation, a double phase accumulator. The number at the end of that story was 96 dB of alias rejection at A4 and 139 dB at C8, measured by compiling the shipping header against a JUCE stub.

That is the audio-rate half of the synth. It runs once per sample and I now have a meter pointed at it.

The other half runs once per processBlock, and I had never pointed anything at it at all. The LFO, the portamento, the unison summing, the phase warp: all of it control-rate code that I wrote by feel, listened to, and shipped. This post is what happened when I finally measured it.

All five are fixed now, and the last section has the after numbers. I am writing them up as they were found, because the interesting part of each one is not the patch, it is why I could not hear it.

The rule I should have written down first

processBlock gets called with whatever buffer size the host feels like. 32 samples in a low-latency live rig, 2048 in a mixing session, and it can change while the plugin is loaded.

So anything you advance once per block is a signal sampled at fs/N, with its own Nyquist at fs/2N:

buffer size	control rate at 44.1 kHz	control Nyquist
128	344 Hz	172 Hz
512	86.1 Hz	43.1 Hz
1024	43.1 Hz	21.5 Hz
2048	21.5 Hz	10.8 Hz
4096	10.8 Hz	5.4 Hz

That table is two lines of arithmetic and it is the whole post. A modulation source that can be set faster than the control Nyquist does not run fast: it folds, exactly like an oscillator above half the sample rate, for exactly the same reason.

My LFO goes to 20 Hz.

1. The LFO is sampled at the buffer size

Here is the entire LFO, verbatim from PluginProcessor::processBlock:

const float lfoRate = lfoRateParam->load();
lfoPhase += (lfoRate / static_cast<float> (currentSR)) * static_cast<float> (N);
if (lfoPhase >= 1.0f) lfoPhase -= 1.0f;
const float lfoVal = std::sin (lfoPhase * juce::MathConstants<float>::twoPi);

lfoVisBuf.write (lfoVal);

const float cutoffMod = lfoVal * lfoCutoffDepthParam->load() * 4000.0f;
const float pitchMod  = lfoVal * lfoPitchDepthParam->load();

One sin() per block. The phase advances by rate * N / fs each time, which is correct bookkeeping: over a second the LFO completes exactly rate cycles of phase. What it does not do is produce rate Hz of modulation, because the sine is only evaluated fs/N times a second.

The condition is the standard one. The modulation is what the knob says while

rate < fs / (2N)        =>        N < fs / (2 * rate)

and folds above it. At rate = 20 Hz and 44.1 kHz that threshold is N = 1102 samples. A 1024-sample buffer is fine. The next power of two is not.

Measured, by replicating those four lines in float32 and taking the FFT of the block-rate sequence:

  set | N=32    | N=64    | N=128   | N=256   | N=512   | N=1024  | N=2048  | N=4096
-------------------------------------------------------------------------------------
  1.0 |    1.00 |    1.00 |    1.00 |    1.00 |    1.00 |    1.00 |    1.00 |    1.00
  5.0 |    5.00 |    5.00 |    5.00 |    5.00 |    5.01 |    5.01 |    5.01 |    5.01
 20.0 |   20.00 |   20.00 |   20.00 |   20.00 |   20.03 |   20.03 |    1.50 |    1.50

At a 2048-sample buffer, the 20 Hz setting produces 1.5 Hz. Not a rough 20 Hz, not a steppy 20 Hz. A different, slower, unrelated frequency: 21.5 - 20 = 1.5, the fold, right where the arithmetic says it will be.

Three things make this worse than it first looks.

The rate knob becomes host-dependent. The same project, the same preset, a different buffer size, and the vibrato is a slow wobble. Nothing in the UI hints at it.

Smoothing hides steps, not folds. The cutoff modulation goes through a 20 ms smoother (smoothCutoffMod.reset (sampleRate, 0.02)), so the staircase gets rounded off on its way to the filter and never sounds like zipper noise. It sounds smooth. It is smoothly at the wrong frequency. A lowpass after the sampler cannot undo aliasing any more than a lowpass after your converter can.

The LFO scope is drawing the bug. lfoVisBuf.write (lfoVal) is fed from the same per-block value, so the on-screen scope in the MOD tab shows the folded waveform faithfully. The evidence was on the front panel the whole time and I read it as "the scope redraws at 30 Hz, of course it looks chunky".

One more sharp edge in those four lines: if (lfoPhase >= 1.0f) lfoPhase -= 1.0f; subtracts once. Past N = fs / rate (2205 samples at 20 Hz) the per-block increment exceeds 1.0 and one subtraction no longer brings the phase back into range, so it grows without bound instead of wrapping. The output is still a sine of a folded frequency, so it does not announce itself, but in float32 an unbounded accumulator quietly coarsens over a long session.

The fix is not subtle: advance the LFO on a fixed sub-block so its rate stops being a function of the host. juce::Synthesiser::renderNextBlock takes MIDI positions as absolute offsets into the buffer, so the same MidiBuffer can be handed to each chunk with only startSample moving, and the voices never notice:

for (int offset = 0; offset < numSamples; offset += kControlBlockSize)
{
    const int chunk = juce::jmin (kControlBlockSize, numSamples - offset);

    lfoPhase += phaseStep * chunk;
    lfoPhase -= std::floor (lfoPhase);      // not a single conditional subtract

    const float lfoVal = std::sin (static_cast<float> (lfoPhase) * twoPi);

    for (int i = 0; i < synth.getNumVoices(); ++i)
        if (auto* v = dynamic_cast<SynthVoice*> (synth.getVoice (i)))
            v->setLFOMod (lfoVal * cutoffDepth * 4000.0f, lfoVal * pitchDepth);

    synth.renderNextBlock (buffer, midi, offset, chunk);
}

kControlBlockSize = 32 puts the control rate at 1378 Hz and the modulation ceiling at 689 Hz, two decades above anything the rate knob can ask for, at any buffer size. The green trace in the figure above is that version: 20.00 Hz whatever the host does. std::floor replaces the conditional subtract for the same reason: it wraps a phase no matter how large the increment gets.

2. Portamento is quantised to the host buffer

Same failure, different knob. From SynthVoice::renderNextBlock:

// Block-rate glide + pitch LFO
const float glideHz = smoothedFreqHz.skip (numSamples);
const float pMod    = smoothPitchMod.skip (numSamples);
const float modBase = glideHz * std::pow (2.0f, pMod / 12.0f);

smoothedFreqHz is a juce::SmoothedValue<float, ValueSmoothingTypes::Multiplicative>, which is the right choice: pitch is logarithmic, so a glide should be a constant ratio per sample and not a constant number of hertz. skip(n) advances the smoother n steps and returns where it landed, so the ramp rate is exactly right.

It is read once per block. The oscillator frequency is therefore piecewise constant over each buffer, and a portamento is a staircase whose step height is set by the host:

cents per step = 1200 * N / (glideTime * fs)

For a one-octave glide in 100 ms:

buffer size	pitch updates	cents per step
64	68.9	17.4
128	34.5	34.8
256	17.2	69.7
512	8.6	139.3
1024	4.3	278.6

At 512 samples a fast glide moves in 139-cent steps, larger than a semitone. At 1024 it is 279 cents and four steps: that is not a portamento, that is an arpeggio. And again the knob behaves differently depending on a setting in a different application.

Unlike the LFO this one has a real cost attached, which is why I suspect past-me did it on purpose and then forgot. Per-sample pitch means calling setFrequency per sample on up to eight unison oscillators per voice, and setFrequency does a log2 for the mip index. The honest middle is a sub-block, which is the same sub-block the LFO now needs: because renderNextBlock is called per 32-sample chunk, skip(numSamples) is handed 32 instead of the host's buffer, and the fix arrives for free. 8.7 cents per step, at every buffer size. That is the green trace above, and 1/32 of the cost of doing it per sample.

3. Cutoff is smooth, pitch is not, and the expensive one is the one I did not need

The two modulation destinations inside the voice are handled differently, three lines apart. Pitch, above, is skip(numSamples): one value per block. Cutoff is inside the per-sample loop:

for (int i = 0; i < numSamples; ++i)
{
    const float cMod = smoothCutoffMod.getNextValue();
    const float env  = adsr.getNextSample();
    svFilter.setCutoffFrequency (juce::jlimit (20.0f, 20000.0f, cutoff + cMod));
    ...
}

getNextValue() per sample. Smooth, correct, and the most expensive line in the voice, because of what JUCE does behind that setter:

void StateVariableTPTFilter<SampleType>::update()
{
    g  = static_cast<SampleType> (std::tan (juce::MathConstants<double>::pi * cutoffFrequency / sampleRate));
    R2 = static_cast<SampleType> (1.0 / resonance);
    h  = static_cast<SampleType> (1.0 / (1.0 + R2 * g + g * g));
}

A std::tan and two divisions, per sample, per voice. Sixteen voices at 44.1 kHz is 705,600 tangents a second, and the loop calls it unconditionally: with the LFO cutoff depth at zero, cMod is a constant and every one of those recomputes the same three coefficients.

So the voice pays per-sample cost for the modulation path that also happens to be easy to make cheap, and takes the block-rate shortcut on the path where per-sample actually costs something. I would defend block-rate pitch to a reviewer. I cannot defend recomputing a filter coefficient 705,600 times a second to apply a modulation of zero.

The fix is a cached comparison, and it costs nothing when the modulation is moving:

const float target = juce::jlimit (20.0f, maxCutoffHz, cutoff + cMod);
if (std::abs (target - lastCutoffHz) > lastCutoffHz * 1.0e-4f)
{
    svFilter.setCutoffFrequency (target);
    lastCutoffHz = target;
}

The threshold is relative, so it is 0.0002 of a semitone at any cutoff rather than a fixed number of hertz that would be inaudible at 8 kHz and a staircase at 40 Hz. With the LFO depth at zero the smoother converges and the tangents stop entirely.

maxCutoffHz is the other half of that line, and a bug of its own: see the small print below.

4. Two of the four warp modes are one warp mode

The oscillator's applyWarp offers None, Sync, Bend and PWM. Here are the last two, verbatim and adjacent in the source:

case 2: // Bend - non-linear phase redistribution
{
    const double k = 0.05 + warpAmount * 0.9;
    return (phase < k) ? phase / (2.0 * k)
                       : 0.5 + (phase - k) / (2.0 * (1.0 - k));
}
case 3: // PWM
{
    const double pw = 0.05 + warpAmount * 0.9;
    return (phase < pw) ? phase / (2.0 * pw)
                        : 0.5 + (phase - pw) / (2.0 * (1.0 - pw));
}

Same constant, same breakpoint, same two branches, same arithmetic. Rename pw to k and the two cases are character for character identical, which is a fact about the source and needs no measurement to settle. Rendering both modes through the oscillator settles it anyway: the two buffers came out bit-identical, maximum sample difference 0.0. (After the rewrite below they differ by up to 1.63, which is the version of that check that passes.)

The dropdown offers four modes and the DSP implements three. Nobody reported it, including me, because the one thing a phase-distortion mode reliably does is sound different from the mode before it, and Bend already does.

The mode that was missing is the interesting one. Pulse-width modulation on a wavetable is not a phase remap at all and cannot be written as one, which is exactly how it ended up as a renamed copy of its neighbour. It is the difference of two reads of the same table a duty cycle apart:

const bool   isPWM  = (warpMode == 3);
const double pulseW = 0.05 + warpAmount * 0.9;

if (isPWM)
{
    double p2 = currentPhase + pulseW;
    p2 -= std::floor (p2);
    s = 0.5f * (readAt (currentPhase) - readAt (p2));
}
else
{
    s = readAt (applyWarp (currentPhase));
}

That needed the single table read to be pulled out into a readAt() lambda (morph blend, mip blend and all), which the non-PWM path now calls once and PWM calls twice. The 0.5 keeps it inside unity: two unit sawtooths a distance w apart differ by at most 2 - 2w, which reaches 1.9 at the narrow end of the range.

Then the part I did not expect. x(p) - x(p + w) is a sum of the harmonics already in the table, with modified amplitudes and phases and nothing new above them. Sync and Bend re-create the slope discontinuities the band-limited tables exist to avoid, so they alias badly. The two-read PWM cannot. Rendered through the shipping oscillator at Amount = 0.75 and measured the same way as the oscillator sweep:

alias-to-signal ratio (dB, lower is better)
  f0 (Hz) |     none |     sync |     bend |      pwm
----------------------------------------------------
    109.7 |    -91.3 |    -18.4 |    -34.9 |    -92.0
    440.1 |   -121.6 |    -12.4 |    -28.1 |   -122.5
   1320.3 |   -142.3 |     -6.2 |    -22.9 |   -142.3

PWM matches the unwarped oscillator to a fraction of a dB. It is the only warp mode in the plugin that does not throw away the mip-mapping the oscillator rewrite paid for.

One footnote from setting up that measurement, which I ran at Amount = 0.75 rather than the obvious 0.5. Bend's breakpoint is k = 0.05 + amount * 0.9, so at Amount = 0.5 you get k = 0.5, both branches collapse to phase, and the map is the identity. The Bend knob does nothing at its own midpoint. I found that by measuring Bend and getting the unwarped column back, digit for digit.

5. Unison at zero detune is a +9 dB knob

The unison summing, from the same render loop:

const float normGain = 1.0f / std::sqrt (static_cast<float> (numU));

1/sqrt(N) is the right normalisation for incoherent sources. Sum N uncorrelated signals and the power adds, so the amplitude goes as sqrt(N) and dividing it out keeps the level constant. That is what a detuned unison stack becomes after a few tens of milliseconds.

It is not what it is at note-on, because startNote does this to all eight oscillators:

for (int u = 0; u < kMaxUnisonVoices; ++u)
{
    unisonOscs[u].setFrequency    (baseFreqHz);
    ...
    unisonOscs[u].reset();          // phase = 0
}

Every unison oscillator starts at phase zero, so for the first cycles they are one signal copied N times. Coherent sum, amplitude N, scaled by 1/sqrt(N):

unison voices	coherent gain	dB
2	1.414	+3.01
4	2.000	+6.02
8	2.828	+9.03

With detune above zero they drift apart and the level settles where the normalisation intends. With detune at exactly zero they never drift, so the voice count stops being a texture control and becomes a +9 dB gain knob that also triples your chance of clipping the FX chain downstream.

The transient version of this is the more musical bug: at any detune setting, the attack of every note is up to 9 dB hotter than its body. I have been hearing that as "the unison has a nice punch to it".

The fix is one line, and the obvious version of it is wrong. Staggering the phases evenly, u / numU, looks like the tidy deterministic choice and is the worst of the three: summing N copies of one waveform at phases k/N cancels every harmonic that is not a multiple of N, so an 8-voice unison at zero detune would come out three octaves up, on 8*f0, with seven eighths of its spectrum deleted. Even spacing is a comb filter wearing a normalisation's clothes.

Random phases are the fix, because random phases are the assumption 1/sqrt(N) was already making:

// Oscillator 0 keeps phase 0 so unison = 1 is bit-identical to before.
unisonOscs[u].resetPhase (u == 0 ? 0.0 : rng.nextDouble());

The generator is seeded from the voice's construction index, so a fresh instance still renders a given note sequence identically twice, which is what you want for an offline bounce. Measured on a 50-harmonic sawtooth over 500 phase draws, as level relative to a single oscillator:

unison voices	phase 0 (before)	random phase, RMS	random, peak
2	+3.01	-0.32	-0.08
4	+6.02	-0.27	+0.65
8	+9.03	-0.31	+0.68

The +9 dB is gone from both the steady state and the attack. What is left is a few tenths of a dB of draw-to-draw variation, which is the phasing that makes an analog unison sound like one.

The small print

Three more things I measured or re-read, kept here because a list of only the dramatic findings is a dishonest list.

The saturator is used outside its documented range. The per-voice drive stage is juce::dsp::FastMathApproximations::tanh, whose header says "You are advised to use input values only between -5 and +5". The drive parameter goes to 10, so the argument does too. Measured against std::tanh:

x	fast tanh	true tanh	dB over unity
5.0	1.00001	0.99991	0.000
10.0	1.00917	1.00000	+0.079
20.0	1.13348	1.00000	+1.088

The Padé approximant stays monotonic and does not blow up; it just stops saturating and creeps above unity, first crossing 1.0 at x = 4.972. At the maximum drive the "soft clipper" overshoots its ceiling by 0.08 dB. That is inaudible and it is still wrong, because the one property I wanted from that function is a hard ceiling at 1.

This is the one I left alone, on purpose. Swapping in std::tanh fixes 0.08 dB and changes the saturation curve of every preset anyone has saved; clamping the argument at ±5 turns a soft knee into a hard corner at high drive. Neither is worth it for 0.08 dB. Measured, judged, documented, unchanged: that is a legitimate outcome for a finding and I would rather write it down than quietly "fix" the sound of the plugin.

The cutoff clamp assumed 44.1 kHz. juce::jlimit (20.0f, 20000.0f, ...) is a fixed ceiling, but the TPT filter needs cutoff < fs/2. Below a 40 kHz sample rate the clamp let through a cutoff above Nyquist, std::tan(pi * fc / fs) went negative, and JUCE's own jassert fires in a debug build. It never bit me because I have never run the plugin at 32 kHz. The ceiling is now jmin (20000.0, 0.49 * sampleRate), computed in prepareToPlay.

The oscillator takes a double and the voice hands it a float. The header argues, at length and correctly, that setFrequency should take a double because a float32 Hz value leaves the tone slightly non-periodic and shows up as leakage skirts at -86 dBc. Then the caller computes:

const float freq = juce::jlimit (20.0f, 20000.0f,
    modBase * std::pow (2.0f, detuneSt / 12.0f));
unisonOscs[u].setFrequency (freq);

The precision was thrown away one line above the call that had been widened to preserve it. The measurement harness passes an exact double, so the rig I built to keep me honest was the one place in the codebase where the argument held. The whole glide and detune path is in double now: a double and an std::pow in double, free, and it makes the header comment true.

And a documentation one, since docs ship too: the repo README still advertised "Four band-limited wavetables (64 harmonics each)", which describes the oscillator I deleted a year ago. CLAUDE.md described the current one. Two files, two different synths, and the one users read was the wrong one. Also fixed, and it is the change I am least proud of needing.

The five, before and after

	before	after
LFO at 20 Hz, N = 2048	1.50 Hz	20.00 Hz, at every buffer size
Octave portamento in 100 ms	139 cents/step at N = 512, 279 at N = 1024	8.7 cents/step, at every buffer size
`std::tan` per second, 16 voices, LFO depth 0	705,600	0
PWM	bit-identical to Bend	a real pulse, and the only warp mode that does not alias (-92.0 dB against -91.3 unwarped)
Unison 8 at zero detune	+9.03 dB	-0.31 dB RMS, +0.68 dB peak

Everything still builds clean in Release x64, and the oscillator sweep from the previous post comes back digit for digit (-121.6 dB at A4, -148.2 at C8), which is the regression test that mattered: the control-rate work moved nothing in the audio-rate path.

Reproducing this

python analysis/measure_modulation.py

The warp table needs the C++ harness first, because it renders through the real oscillator:

cl /std:c++17 /O2 /EHsc /I analysis\juce_stub /I Source analysis\measure_warp.cpp /Fe:analysis\measure_warp.exe
analysis\measure_warp.exe analysis/data

One honest caveat about method, because it differs from the oscillator work. plot_oscillator.py and measure_warp.cpp measure the shipping header, compiled as-is against a minimal JUCE stub: those numbers come from the code that runs in the product. The LFO, glide and unison paths live in SynthVoice.h and PluginProcessor.cpp, tangled up with APVTS and juce::Synthesiser, so measure_modulation.py replicates them rather than compiling them, four to six lines at a time, quoted beside the original above.

That is a weaker claim and worth stating plainly. The warp findings do not depend on it at all, being rendered audio. Nor does the identity of the two modes, which is a textual fact about the source, or the sqrt(N) unison gain, which is arithmetic on one line of code. The LFO fold and the glide staircase are arithmetic too (N = fs/2f and 1200N/(t*fs)); the replication only draws them.

What I would take from this

Write down the control rate the same way you write down Nyquist. fs/2N is the ceiling on every modulation source in the plugin, and N belongs to the host, not to you.
A parameter range that the implementation cannot honour is a bug in the range. A 20 Hz LFO in a block-rate modulator is a knob that lies above about a third of its travel.
Smoothing is not sampling. A 20 ms smoother turns a staircase into a ramp and leaves an alias exactly where it was. It made this bug harder to hear, not smaller.
Normalisation laws have assumptions in their names. 1/sqrt(N) is the incoherent law. If you reset every source to phase zero, you have just guaranteed the coherent case for the first cycles, and forever at zero detune.
Two adjacent switch cases are worth diffing. Not reading, diffing. I have read that function a dozen times and my eyes matched k against pw and moved on.
Measure the parts you feel confident about. I measured the oscillator because I already suspected it. The LFO I never suspected, and it is the worst one on the list.
The front panel was showing it. The LFO scope had been drawing the folded waveform since the day I wrote it.
The tidy fix can be the worst one. Evenly spaced unison phases look more principled than random ones and delete most of the spectrum.
Leaving something unfixed is a result too. The saturator overshoots by 0.08 dB and I am not touching it, because the alternative is silently changing how every saved preset sounds.

SYNTH/1 is MIT licensed and on GitHub, analysis/ folder included: measure_oscillator.cpp and plot_oscillator.py for the audio-rate story, measure_warp.cpp and measure_modulation.py for this one.

I'm an audio DSP student at UPC. I build VST plugins and instruments you play with your hands.

My first open source contribution was a bug nobody could hear

Lluis Estape — Sat, 12 Sep 2026 14:39:32 +0000

I am an audio DSP student, and for a long time "contribute to open source" sat on my list next to "learn to swim properly". Something I would clearly do at some point, with no first step attached to it.

This is what the first step turned out to be: a bug in Surge XT, a free synthesizer, where notes started up to 15 milliseconds late and no one had noticed because you cannot hear a delay you have nothing to compare it against.

The pull request is in review as I write this. What follows is the part I would have wanted to read before starting, including the four times I was wrong.

Picking something

I did not go looking for a project. I went looking for an issue I could hold in my head.

The one I picked was titled BLIT oscillators are a bit late. It had three properties I would now look for on purpose:

A symptom stated as a measurement, not as a feeling. "Late" is checkable. "Sounds weird" is not.
A small surface. Three files, one function each.
No product decision inside it. Nobody had to agree on what the feature should be. There was a right answer and the code was not producing it.

Issues that are open for a while are not always hard. Sometimes they are open because they are boring, or because they sit in a corner of the codebase the maintainers rarely touch. That is a good place for a newcomer to be useful.

Reading until the bug fits in one sentence

Surge has an oscillator setting called retrigger. With it on, every note starts at the same point in the waveform. With it off, notes are supposed to start at a random point, so stacked voices do not phase-lock into an artificial-sounding block.

The code did this:

double st = 0.5 * drand * storage->note_to_pitch_inv_tuningctr(detune);
oscstate[i] = st;

I stared at that for a while before the problem clicked, and the click was a vocabulary problem. oscstate is not phase. It is the remaining phase space before the next impulse fires. The oscillator counts it down and emits when it reaches zero.

So with the output buffers freshly cleared and the level tracking at zero, there is nothing to emit until that countdown finishes. The voice is not starting at a random phase. It is silent, and then it starts at phase zero.

That is the whole bug in one sentence: it was a random delay, not a random start phase.

I could not have written the fix before I could write that sentence. Every hour I spent reading instead of typing paid for itself twice.

Measuring before touching anything

I wrote a test that initialised each oscillator 300 times and counted samples until the first non-zero output. Before any fix, in oversampled samples:

Oscillator	MIDI 24	MIDI 60	MIDI 96
Classic	665.6	82.8	10.0
Wavetable	1263.1	167.5	21.7
S&H Noise	655.4	81.5	9.9

It halves per octave, which is what a fixed fraction of a cycle should do. At MIDI 24 that is 7.5 ms off the front of the attack on average, and around 15 ms at worst. On a bass note with a fast attack, that is the difference between a note that lands and a note that arrives.

Those numbers did more for the pull request than the patch did. They turned "this feels off" into something a maintainer could check in thirty seconds.

Three oscillators, three different fixes

The temptation was to write one patch and apply it three times. That was wrong, and working out why was the interesting part.

Classic builds its waveform as a four segment cycle, tracking the current level and a DC slope across each segment. To start mid-cycle you have to replay that bookkeeping up to the segment you are landing in, otherwise the level is wrong and the waveform is wrong from there on.

Wavetable emits pure steps with no DC ramp. So it starts at a random index and lets the first impulse go through the existing sinc convolution. The opening step comes out band limited for free. This one ended up being the cleanest of the three because I did less to it.

S&H Noise holds a random value by construction. There is no level to reconstruct. It draws one and starts partway through the segment holding it.

Same bug, three shapes, because the thing being reconstructed is different in each.

Four times I was wrong

This is the section I would actually read.

1. I ran a subset of the tests

I ran the [dsp] tag. 856,979 assertions, all green. I felt good.

The [osc] tag was red. There was a serious bug in my S&H change: I had copied a pattern from the Classic oscillator that used a first_run flag, but in S&H that flag was set once in the constructor and never cleared, because until then nothing read it. My new code ran on every audio block, forever.

Run the whole suite. A tag is a filter you chose while holding an assumption.

2. I argued with the evidence

When those tests failed, I reasoned that they could not be my fault: my change only affected the first block, and the failing tests measured steady-state frequency. A transient cannot shift a steady-state measurement.

That reasoning was airtight and the conclusion was false. I reverted my S&H change alone, the tests passed, and my elegant argument was worth nothing. The flag was never cleared, so there was no transient. It was every block.

When a measurement disagrees with your reasoning, the measurement is not the thing that needs explaining away.

3. I tested a stale binary

Twice. The build command failed with cmake: command not found, the test runner ran anyway using the previous binary, and I spent time interpreting results from code that no longer existed.

Now I read the first line of build output before I read the last line of test output.

4. My test harness never reached the code

This one is my favourite, because it bit me three times before I recognised the pattern.

In Surge, an oscillator reads its parameters from a scene data block, not from the parameter objects you set. If you set the parameter and forget to push it across, the oscillator runs on zeros, and zeros are usually a valid configuration that produces plausible-looking output.

So I had a measurement showing my sync fix did nothing (the parameter never arrived), and later a correlation test reporting a beautiful 0.9995 on a waveform that was degenerate because two of its four segments had collapsed to zero length.

A test harness is code. It has bugs. When a result surprises you, suspect the harness before you suspect the thing you are measuring.

The review was the best part

I opened the pull request expecting either silence or a nitpick about brace style. Instead the maintainer wrote several paragraphs and found things I had missed:

The wavetable oscillator recomputes its mipmap level only at the start of a cycle. Starting mid-cycle skipped it, so the first block ran 1137 convolutions where the steady state needs 49. Not audible, but a CPU spike on every note-on.
My replay loop used > where it needed >=, so a random draw of exactly 1.0 would fall out of the loop with the wrong state. Probability about one in sixteen million, which is roughly once per hour of dense playing.
The seeding computed the oscillator period without the sync parameter, while the running code includes it. A synced voice started at the wrong rate. At an extreme setting, the first block ran at 48% of the correct rate.

One of his suggestions I did not follow literally, and saying so was fine. He proposed guarding a whole block on an extra condition. Tracing it, that block also increments a sample counter, which would have fired dozens of times in the first block. I split the guard instead and explained why in the reply. He was fine with it. The suggestion was pointing at a real bug, and the specific line was the fastest way to describe where it lived.

The thing I almost shipped without checking

The maintainer asked for a test proving that retrigger-off output is the retrigger-on output shifted in time. I wrote it. It passed. I was pleased with it.

Then I broke the oscillator on purpose to watch the test catch it.

It did not. It passed on broken code.

The reason is that the Classic oscillator resets its level absolutely at the start of each cycle, so a seeding error erases itself within one cycle, and my comparison window started after that. The test was measuring "does it eventually produce the right waveform", which is a real property, and not the one I had claimed.

A test you have never seen fail is a decoration. Break the code and watch it go red before you believe it.

What I would tell myself

Pick an issue whose symptom is a number.
Read until you can state the bug in one sentence. If you cannot, you are not ready to fix it.
Measure first. The before-and-after table is what gets your pull request read.
Run everything, not the subset that matches your mental model.
Suspect your harness.
Break your own test on purpose.
Write down why you did not follow a suggestion, rather than quietly not following it.

The patch itself is maybe forty lines. Everything else was working out what those forty lines needed to be, and then finding out which parts of my confidence were unearned.

The pull request is surge-synthesizer/surge#8543 if you want to read the full thread. The review is more instructive than the diff.

I replaced a GNN's message function with a 4-qubit quantum circuit

Lluis Estape — Wed, 09 Sep 2026 06:37:44 +0000

A build log on QTGNN v2, what happens when the message function in a graph attention network is a variational quantum circuit instead of a matrix multiply.

Not investment advice. This is a machine learning experiment. Nothing here is a trading system, I make no performance claims, and the limitations section at the end is the most important part of the post.

The idea in one sentence

A graph neural network passes messages along edges. Normally that message function is a learned linear map. I made it a 4-qubit variational quantum circuit and pointed the whole thing at a graph whose nodes are stocks and whose edges are rolling price correlations.

Why a graph at all

Most price prediction models treat each ticker in isolation: feed in AAPL's history, predict AAPL's next move. That throws away the thing every trader knows: assets move together. NVDA and META are not independent draws, and neither are JPM and GS.

That relational structure is exactly what GNNs are for. So the 10 tickers become nodes in a fully-connected directed graph, and the edge weight w_ij is the Pearson correlation over a rolling 30-day window of normalised closing prices.

The rolling window is what makes this interesting rather than decorative: the graph is dynamic. Connectivity changes at every timestep, so the model sees the market's structure shift between regimes rather than assuming one fixed correlation matrix for two years of history.

The universe is 10 S&P 500 names across 5 sectors: AAPL, MSFT, GOOGL, NVDA and META in tech, JPM and GS in finance, JNJ in health, XOM in energy, AMZN in consumer. Roughly 500 trading days of OHLCV from yfinance. Price and volume are Min-Max normalised separately per ticker, because volume's raw magnitude would otherwise dominate price entirely.

What each node knows

Every node carries a 31-dimensional feature vector at every timestep, assembled from four sources:

Temporal (GRU). A Gated Recurrent Unit reads the last SEQ_LEN = 10 trading days of price and volume jointly as a 2-D sequence. Its final hidden state h ∈ ℝ³² is the temporal summary.

Sentiment (FinBERT). Recent headlines per ticker are pulled from Yahoo Finance and passed through ProsusAI/finbert, a BERT fine-tuned on financial text. It emits a 3-vector of (positive, negative, neutral) probabilities, averaged across headlines.

Macro. Three series aligned to the same trading calendar, each with an actual economic reason to be there:

Symbol	What it is	Why it belongs
`^VIX`	CBOE Volatility Index	implied volatility, the market's fear gauge
`^TNX`	10-year Treasury yield	the risk-free rate; high yields pull capital out of equities
`GLD`	SPDR Gold Shares	safe-haven demand, rises in risk-off regimes

Sector. A 5-dimensional one-hot.

Concatenated:

z_i = [ h_GRU ‖ sentiment_i ‖ sector_i ‖ macro_t ]  ∈ ℝ⁴³
        32          3            5          3

Note the two different numbers. The raw node vector is 31-dimensional, because the price and volume histories enter as 10 days each. After the GRU has folded those 20 numbers into a 32-dimensional hidden state, the embedding the graph actually passes around is 43-dimensional.

The quantum part

Here is the actual novelty. In a standard graph attention network, the message from node j to node i is a learned linear transform of j's embedding. In QTGNN it is a circuit:

m_{j→i} = QCircuit( tanh(W·z_j)·π ,  θ ,  corr_ij )

The node embedding is squashed with tanh and scaled by π, which maps it into a rotation angle: the thing a qubit can actually consume. The correlation corr_ij is injected as its own rotation, so the edge weight is not a scalar multiplier bolted on afterwards; it participates in the state evolution.

Two ideas are stacked here.

Data re-uploading (N_REUP = 4). Pérez-Salinas et al. (2020) showed that repeating the data encoding interleaved with trainable layers lets a quantum model represent arbitrary Fourier series of its input, making it a universal function approximator on the device. Encode once and you are stuck with a very limited function class; encode four times and the expressivity opens up. It is the quantum analogue of depth.

A Hardware-Efficient Ansatz (N_Q_LAYERS = 3). The trainable part: alternating single-qubit RY and RZ rotations with nearest-neighbour CNOT entanglers. "Hardware-efficient" means it is built from gates real devices actually implement natively, rather than a mathematically elegant ansatz that compiles into a thousand physical operations.

Measuring ⟨Z₀⟩…⟨Z₃⟩ ∈ [−1,1] gives a 4-dimensional message vector. From there it is ordinary GAT machinery: a learnable linear layer produces attention coefficients α_ij, softmax-normalised per destination node; aggregated messages combine with the node's own embedding through a residual connection and LayerNorm. A second QGAT layer refines, and a linear readout maps each node's 4-D quantum output to one scalar, the predicted next-day normalised price delta.

The whole thing trains end-to-end. PennyLane differentiates through the circuit, so the quantum weights θ sit in the same backward pass as the GRU.

Two training details that are not optional

Never shuffle a financial time series. Shuffling before splitting leaks the future into the training set, and the model will happily report a beautiful validation number that means nothing. QTGNN uses walk-forward validation: the training window grows sequentially and each validation window immediately follows its training period, 5 folds over 500 days, validation fixed at 30 days.

Two learning rates, and the quantum one is 10× smaller. Adam runs with classical weights at 1e-2 and quantum circuit weights at 1e-3. This is a hedge against barren plateaus: the phenomenon where gradients in a variational circuit vanish exponentially with qubit count and depth. On a plateau, a learning rate tuned for the classical half will push the circuit parameters around on essentially no gradient signal, which is worse than not moving. A smaller step is the cheap mitigation. (The real ones, local cost functions, smart initialisation and shallower ansätze, are future work.)

Everything else:

Parameter	Value
`EPOCHS` / `PATIENCE`	60 / 10 (early stopping)
`BATCH_SIZE`	8 graphs
`SEQ_LEN` / `GRU_HIDDEN`	10 days / 32
`N_WIRES` / `N_Q_LAYERS` / `N_REUP`	4 / 3 / 4
`CORR_WIN`	30 days
`N_FOLDS` / `VAL_SIZE`	5 / 30 days

Loss is MSE on the next-day normalised price delta.

There is a second metric printed each epoch, and it is worth stopping on because I had it wrong. My report calls it an annualised Sharpe ratio, S = (μ_e/σ_e)·√252, where μ_e and σ_e are the mean and standard deviation of the per-sample prediction errors. That is not a Sharpe ratio. A Sharpe ratio is mean excess return over the standard deviation of returns; mean error over standard deviation of error is a different quantity, and it points the wrong way: a model with a large, consistent bias scores wonderfully on it, because a big μ_e over a small σ_e is exactly what a confidently wrong model produces.

So it is not a trading metric, it is closer to an inverse coefficient of variation of the residuals, and the report's thresholds ("above 1.0 is acceptable in live trading") do not transfer to it at all. Leaving it labelled Sharpe would have been the single most misleading thing in the project, which is a good argument for writing the post: I only caught it because I had to explain the formula in prose.

The 50-qubit wall

Everything above runs on PennyLane's default.qubit: a simulator, on my CPU. This is worth being precise about, because "quantum machine learning" invites the wrong assumption.

An N-qubit state lives in ℂ^(2^N). For 4 qubits that is a 16-dimensional complex vector, and every gate is a dense matrix multiply against it. Perfectly cheap.

That exponential is the entire story of the field. At ~50 qubits the state vector no longer fits in any machine that exists, which is simultaneously why simulation stops and why real quantum hardware is interesting. At 4 qubits I am nowhere near that line, which means I get none of the theorised advantage. What I have is a circuit that is a differentiable, entangling, non-linear function with an unusual inductive bias, that happens to be cheap enough to simulate exactly.

That is a legitimate thing to study. It is not a speedup, and anyone telling you their 4-qubit simulated model beats a classical baseline because of quantum should be asked which baseline.

What I cannot claim

The limitations are the honest half of this project:

Simulated hardware. default.qubit on CPU. Any real advantage requires QPU execution or at minimum GPU simulation via lightning.gpu.
10 tickers is not a portfolio. Real inference needs sparse graph construction and mini-batch graph sampling to reach S&P 500 scale. A fully-connected graph is O(N²) messages, and each message is a circuit evaluation.
Sentiment is computed once at startup. FinBERT scores are static for the whole run. A production system would re-score daily off a live feed, as it stands, the sentiment feature is closer to a constant than a signal.
No trading metric at all, let alone transaction costs. Nothing here measures profit. There is no back-test, no position sizing, and therefore no spreads, market impact or fees, all of which eat exactly the kind of small edge a next-day model would produce.
Single-step only. Multi-horizon forecasting would need an autoregressive decoder.

Next steps, in the order I would do them: GPU simulation, a live news feed, 50+ tickers with sparse attention, and a real back-test with position sizing and costs, so that there is finally a number that means profit rather than error.

What I actually took away

The interesting question in hybrid QML is not "is it faster", at this scale it obviously is not. It is where in the architecture you put the circuit. Most hybrid models bolt a variational circuit on as a classifier head, which makes it a small non-linear layer with an expensive gradient. Putting it in the message function means it runs once per edge, sees a pair of nodes and their relationship, and its output has to mean something relational. That is a much more specific role, and it makes the resulting model easier to reason about than "and then some qubits."

The rest of what I learned was not quantum at all. It was that walk-forward validation is non-negotiable, that a single learning rate across a hybrid model is a silent failure mode, and that a static feature dressed up as a dynamic one will quietly do nothing while you tune everything around it.

References: Pérez-Salinas et al., Data re-uploading for a universal quantum classifier (Quantum 4, 226, 2020) · Bergholm et al., PennyLane (arXiv:1811.04968) · Veličković et al., Graph Attention Networks (ICLR 2018) · Yang et al., FinBERT (arXiv:2006.08097) · Cerezo et al., Variational quantum algorithms (Nature Reviews Physics 3, 2021) · Orús et al., Quantum computing for finance (Reviews in Physics 4, 2019).

I'm a UPC student who mostly builds audio DSP and real-time systems. QTGNN was the project where I wanted to find out what a variational circuit actually feels like to train, and the answer was "slow, and unusually sensitive to your learning rate."

I built a drone Ground Control Station in Electron, using LiDAR for autonomous navigation

Lluis Estape — Tue, 08 Sep 2026 07:16:43 +0000

A build log on the ground station for an autonomous warehouse inventory drone, ROS2 on the aircraft, Electron on the laptop, and nothing in between but a WebSocket.

The problem

The drone is a hexacopter that flies through a warehouse on its own, builds a 3D map as it goes, reads the barcodes off the shelves, and hands you a geolocated inventory. It runs ArduCopter on a Pixhawk for flight and ROS2 Jazzy on a Raspberry Pi 5 for everything else: a Unitree 4D LiDAR feeding Point-LIO SLAM, two Pi cameras, and barcode detection.

That is the aircraft. The other half of the problem is the laptop.

Whoever is standing in the warehouse holding that laptop needs to see the telemetry, arm the drone, watch the map build, and read the barcode log. And critically: they should not need ROS installed to do it. A ground station that requires a full ROS2 desktop install on every machine that wants to look at the drone is a ground station that only I can run.

So the constraint I set was: the GCS is an ordinary desktop app. Download an installer, double-click, connect. No ROS on the client, ever.

The architecture, and the one decision that shapes it

┌─ Raspberry Pi 5 (ROS2 Jazzy) ──────────┐      ┌─ laptop (no ROS) ──────┐
│  MAVROS ──► /mavros/*                  │      │                        │
│  Point-LIO ──► /scan, /map, pose       │ WS   │  Electron              │
│  camera_publisher.py ──► CompressedImage├─────►│   └ renderer           │
│  barcode_detector.py ──► /barcode/*    │ 9090 │      roslib.js         │
│  brain_node.py ──► /brain/planned_path │      │      canvas 2D         │
│      └─► /mavros/setpoint_position/local      └────────────────────────┘
│  gcs_control.py ──► /gcs/cmd, /gcs/status
│  rosbridge_server ─────────────────────┘
└────────────────────────────────────────┘

Or, as the team drew it, the ROS2 node graph on the aircraft side, with the LiDAR feeding SLAM, SLAM feeding both the brain and MAVROS, and MAVROS driving the Pixhawk:

rosbridge is the whole trick. It exposes every ROS2 topic as JSON over a WebSocket on port 9090. Once that is running, a browser is a first-class ROS client, roslibjs subscribes to /mavros/battery exactly the way a Python node would, and the message arrives as a plain JavaScript object.

Which means the renderer needs no Node APIs at all. The Electron window runs with:

webPreferences: {
  preload: path.join(__dirname, 'preload.js'),
  contextIsolation: true,
  nodeIntegration: false,
}

and the preload file is empty. Nothing is bridged from main to renderer, because nothing needs to be. My preload.js is three lines of comment explaining why it is otherwise blank.

One packaging gotcha worth writing down: roslib is a dependency in package.json, but the renderer loads a bundled copy from renderer/lib/roslib.js, not from node_modules. After electron-builder packages the app, node_modules is inside an asar archive that a plain <script src> in the renderer cannot reach. Copying the library into the renderer folder is unglamorous and it is what makes the built installer work.

No framework, no bundler

The whole UI is one HTML file with inline CSS, one 1,700-line app.js, and the Canvas 2D API. No React, no build step, no transpile. npm start runs the actual shipping code.

I want to defend that, because it is not laziness. Almost every widget here is a drawing: an artificial horizon, a gauge needle, a thrust ring, a point cloud, an occupancy grid. React's value is reconciling a DOM tree against state, but there is no DOM tree to reconcile when the answer is "repaint this canvas at 60 fps from the latest telemetry." A framework would sit between the ROS callback and ctx.fillRect and do nothing but add a frame of latency and a build directory.

So the pattern is deliberately dumb:

const S = { }                       // one shared state object

sub('/mavros/battery', 'sensor_msgs/BatteryState', m => {
  S.batPct = m.percentage * 100     // callbacks only ever write to S
  S.batV   = m.voltage
})

function frame () {                 // rAF loop only ever reads from S
  drawHorizon(); drawGauges(); drawNavMap()
  requestAnimationFrame(frame)
}

Sixteen subscriptions write into S. One requestAnimationFrame loop reads it. Nothing else in the app coordinates anything. Rendering is decoupled from message arrival for free, a topic publishing at 200 Hz and one publishing at 1 Hz both just leave their latest value in S, and the frame loop picks up whatever is there.

Telemetry: 16 topics, one table

The MAVROS side is where a GCS earns its name. The full subscription set:

Topic	Type	Feeds
`/mavros/vfr_hud`	`mavros_msgs/VFR_HUD`	speed, climb rate, heading
`/mavros/altitude`	`mavros_msgs/Altitude`	altitude bar
`/mavros/battery`	`sensor_msgs/BatteryState`	battery % and voltage
`/mavros/imu/data`	`sensor_msgs/Imu`	attitude → artificial horizon
`/mavros/local_position/velocity_body`	`geometry_msgs/TwistStamped`	body-frame velocity
`/mavros/global_position/global`	`sensor_msgs/NavSatFix`	GPS position + trail
`/mavros/gpsstatus`	`mavros_msgs/GPSRAW`	fix type, satellite count
`/mavros/state`	`mavros_msgs/State`	armed state, flight mode
`/mavros/rc/out`	`mavros_msgs/RCOut`	motor PWM, channels 1–6
`/scan`, `/map`, `/slam_toolbox/pose`	LiDAR + SLAM	the SLAM tab
`/barcode/detection`, `/detection/volume`	`std_msgs/String`	inventory log
`/camera/{forward,down}/image_raw/compressed`	`CompressedImage`	the video panels

The IMU one is the only piece of real maths on the client. MAVROS publishes attitude as a quaternion; the horizon needs Euler angles:

const yaw = Math.atan2(2*(q.w*q.z + q.x*q.y), 1 - 2*(q.y*q.y + q.z*q.z))

And the motor ring is a small lesson in reading someone else's convention. /mavros/rc/out gives you PWM in microseconds, 1000–2000, per channel. Turning that into a percentage is trivial; the part that took reading the docs is that motor numbering is not spatial. M1 through M6 on a hexacopter sit at specific angular positions with specific rotation directions, and if you lay them out in the order the array arrives, you get a diagram that looks plausible and is wrong. The positions in drawHexDiagram() match the PX4/QGroundControl actuator layout, so a pilot who has used QGC reads it correctly on the first glance.

Two ways to get video, because one was not enough

Camera streaming is where I ended up with a genuinely dual path, and both paths earn their keep.

Path one, MJPEG through a plain <img>. A Flask server on the Pi serves multipart/x-mixed-replace on port 8080 and the dashboard points an <img> at it. Chromium's own decoder does all the work; the JS cost is zero. On connect the app derives the URL from the rosbridge host automatically:

connectMJPEG(`http://${host}:8080/cam1`)   // falls back to a test pattern, retries every 3 s

When the stream is not up, the canvas underneath draws SMPTE colour bars and "NO SIGNAL". It is a small thing that makes the app feel finished rather than broken.

Path two, sensor_msgs/CompressedImage over rosbridge. rosbridge base64-encodes the JPEG bytes into the JSON message. Decoding that in the renderer:

const raw = atob(m.data)
const buf = new Uint8Array(raw.length)
for (let i = 0; i < raw.length; i++) buf[i] = raw.charCodeAt(i)
createImageBitmap(new Blob([buf], { type: 'image/jpeg' })).then(bitmap => {
  ctx.drawImage(bitmap, 0, 0, W, H)
})

createImageBitmap is the important call; it decodes off the main thread and hands back something drawImage takes directly, so a 30 fps stream does not stall the frame loop.

This path is slower than the <img> one, and I keep it because it can do things the fast path cannot: it carries the annotated feed from barcode_detector.py with detection ROIs already drawn on it, and because the frames land as pixels in my canvas I can rotate and channel-swap them. Both of which I needed. The forward camera is mounted upside down (rotation: 180) and one of the Pi cameras publishes with red and blue swapped, which is a one-line fix in the draw call and a much bigger one on the Pi.

A scan is worthless without a position

That screenshot is the whole product in one frame, and it is worth reading carefully. The green box is barcode_detector.py's ROI. P003GUA is the decoded code. The overlay in the top-left is the SLAM pose at the moment of the scan (x:1600.77 y:-2482.32 z:0.00) burned into the frame by the detector, not added by the GCS. The table underneath pairs each code with that position, and the log on the right shows the row landing in the database.

That is what "geolocated inventory" actually means in practice: a barcode is worthless unless you know where it was, and the only thing that knows where the drone was is SLAM. Tagging the detection at the moment of detection (on the Pi, in the same process that read the code) is what keeps the two from drifting apart. Export to CSV/Excel is one button.

800,000 points per scan, drawn with fillRect

The SLAM tab is the one that surprises people. Point-LIO publishes roughly 800,000 points per scan from the Unitree LiDAR, and the viewer renders them coloured by height.

Two things make this survivable on a laptop:

Draw only when visible. drawSLAM() is called from the frame loop only when S.activeView === 'slam'. On the dashboard tab, the SLAM subscriptions still run and still update S, but nothing paints. That one guard is the difference between a smooth app and a hot one.

The occupancy grid is cells, not pixels. nav_msgs/OccupancyGrid arrives as a flat array with a resolution in metres per cell, so each cell is one fillRect at the grid's own scale, not a per-pixel ImageData write. The LiDAR overlay draws on top of it in the SLAM pose frame at 60 px/m.

Colouring by height is what turns the cloud into a room. Shelving units come out as vertical bands, the floor is a plane, and you can see the aisle. It is the same data either way; the ramp is what makes it legible.

The brain node: what actually flies the mission

Go back to the dashboard screenshot for a second. There is an orange dashed line running through it, labelled origin and wp-1, and a badge in the corner reading WP 1/5: ORIGIN. Neither of those is telemetry. They come from a node I have not introduced yet, and it is the one that makes the word "autonomous" mean anything.

brain_node.py is the mission planner. It is about 175 lines and it does four things:

1. Waypoints live in SQLite, not in the code. Two tables (missions and waypoints) in ~/brain_data.db, with an active flag picking which mission runs. A brand-new database seeds itself with a 5 m square at 5 m altitude so the node has something to do on first launch, and you edit the DB to match the real environment.

Putting the route in a database rather than a constant is the difference between "re-flash the Pi to change the route" and "run one UPDATE". For a warehouse, where the route is the shelf layout, that matters.

2. Position comes from SLAM, not GPS. This is the design decision the whole node hangs on:

self.create_subscription(Odometry, '/Odometry', self._on_odom, 10)

/Odometry is Point-LIO's output. Look at any screenshot in this post and the top-right corner says NO GPS: because there is no GPS indoors. A warehouse is exactly the environment where the usual position source does not exist, so the LiDAR SLAM odometry is the position source. The node does subscribe to /mavros/global_position/global, but only to keep the fix around; the control loop never reads it.

3. A 10 Hz loop that is deliberately boring.

def _tick(self):
    wp = self.waypoints[self.wp_idx]
    if dist2d(self.slam_x, self.slam_y, wp['x'], wp['y']) < ARRIVE_DIST:
        self.wp_idx += 1                       # arrived, advance
        return
    sp = PoseStamped()                          # otherwise, keep asking
    sp.pose.position.x = float(wp['x'])
    sp.pose.position.y = float(wp['y'])
    sp.pose.position.z = float(wp['z'])
    self._pub_sp.publish(sp)                    # → /mavros/setpoint_position/local

That is the entire autonomy loop: am I close enough to the current waypoint? If yes, target the next one. If no, publish this one as a setpoint, again.

The restraint is the point. The brain does not compute trajectories, ramp velocities or tune anything; it publishes a position setpoint and lets ArduCopter's own controller work out how to get there. Trying to out-fly the flight controller from a Python node at 10 Hz over ROS is how you get a drone that fights itself. The division of labour is: ArduCopter flies, the brain decides where.

4. It publishes its own plan for the GCS to draw.

self._pub_path.publish(String(data=json.dumps({
    'mission': self.mission_name, 'wp_index': self.wp_idx,
    'done': self.done, 'waypoints': self.waypoints,
    'slam_pos': {...},
})))

One JSON string on /brain/planned_path at 1 Hz. The renderer subscribes to it, draws the waypoints as the orange dashed route, and turns wp_index into that WP 1/5 badge, green and reading "Mission complete" when done flips.

That last part is why the GCS map has two lines. The blue one is where the drone actually went, from SLAM. The orange dashed one is where the brain intends to go. Drawing both, from two independent sources, means the gap between them is visible in real time, and that gap is the only honest measure of whether the autonomy is working.

One honest gap. ARRIVE_DIST is 1.5 m: the conservative value that flew, and considerably looser than the waypoint radius the simulations below suggest is achievable. Tightening it, and pushing a denser waypoint list into the missions table to match, is the obvious next step and it has not been flown yet.

Before any of it flew: Monte Carlo

You cannot iterate on a warehouse mission by flying it. Battery is ten minutes, the room has to be free, and a bad waypoint list is a drone in a shelf.

So the route was validated in simulation first: a physics-based flight simulator plus a Monte Carlo runner that flies the same mission over and over with noise injected into it. Two separate noise sources, because they are physically different things, LiDAR noise corrupts what the drone perceives, motor noise corrupts what it achieves.

The simulated stack mirrors the real one node for node, with the aircraft replaced by an integrator:

Two things worth flagging about that diagram, because they are differences rather than details. It is ROS 2 Humble, while the aircraft runs Jazzy, the simulation predates the flight stack. And in simulation the controller is ours: a proportional law v = K_p × (target − position) publishing velocities on /drone/cmd_vel. On the real drone, that job belongs to ArduCopter and the brain only publishes a position setpoint. The simulation had to model a controller precisely because it did not have one.

It also explains a bit of archaeology in the GCS: the first version of the renderer subscribed to /drone/pose as a Float32MultiArray and to /drone/cmd_vel: the simulation's topics, not MAVROS's. The ground station was built against the simulated drone weeks before there was a real one to point it at.

The ideal route is the dashed line, the milestones are the red dots, and the blue bundle is every simulated run. Where the bundle stays tight, the route survives realistic sensor noise; where it fans out, it does not. That is a question worth answering with numpy in an afternoon rather than with a drone and a shelf.

The feature I did not plan: finding the drone

Here is the thing nobody warns you about. In a lab, the Pi is at 192.168.1.42 and you type it once. In a warehouse (on a hotspot, on a different subnet, on someone else's phone tethering) the Pi is at some address you do not know, and the person holding the laptop is not going to SSH in and run ip addr.

So the connection popover has a Scan button that finds it. In a browser sandbox, with no Node APIs.

First, discover the local subnet. There is no API for "what is my IP" in a renderer, but WebRTC leaks it in ICE candidates:

function getLocalIP () {
  return new Promise(resolve => {
    const pc = new RTCPeerConnection({ iceServers: [] })
    pc.createDataChannel('')
    pc.createOffer().then(o => pc.setLocalDescription(o))
    pc.onicecandidate = ({ candidate }) => {
      if (!candidate) return
      const m = /([0-9]{1,3}(?:\.[0-9]{1,3}){3})/.exec(candidate.candidate)
      if (m && !m[1].startsWith('127.')) { pc.close(); resolve(m[1]) }
    }
  })
}

(This is the same behaviour browsers spent years trying to suppress for fingerprinting reasons. Inside a desktop app talking to hardware on the same LAN, it is exactly the right tool.)

Then probe the /24 for anything with port 9090 open, in batches, with a short timeout:

const BATCH = 40   // parallel probes
const TOUT  = 400  // ms per probe

for (let start = 1; start <= 254; start += BATCH) {
  const tasks = []
  for (let i = start; i <= Math.min(start + BATCH - 1, 254); i++) {
    tasks.push(probeWS(`ws://${subnet}.${i}:${port}`, TOUT).then(ok => {
      if (ok) onFound(`${subnet}.${i}`)
    }))
  }
  await Promise.all(tasks)
}

A failed WebSocket connection is a fast, cheap probe, you never complete a handshake, you just see whether the socket errors before the timeout. 254 addresses in seven batches of 40 at 400 ms each is about three seconds, and the found hosts show up as clickable rows. The URL then lives in localStorage, so it is remembered next launch.

Three seconds of clever hack, and the app stopped needing me standing next to it.

Controlling the Pi from the dashboard

The last piece closes the loop. Early on, every demo started with me SSHing into the Pi to launch SLAM, then the camera, then MAVROS, in the right order, in separate terminals. That is fine for a developer and impossible for a demo.

So gcs_control.py runs permanently under systemd next to rosbridge, and it is a process supervisor driven by a ROS topic:

# Subscribes:  /gcs/cmd     {"action":"start"|"stop","service":"slam"|"camera"|"mavros"|"brain"}
# Publishes:   /gcs/status  {"slam":"running","camera":"stopped",...}  @ 1 Hz

Each service is a command line it knows how to spawn, with stdout going to ~/gcs_logs/<service>.log. The dashboard gets a SERVICES panel with a green dot and a STOP button per service, and the operator never opens a terminal.

One deployment note that cost me an evening: ros-jazzy-rosbridge-suite is not available via apt on the Pi. I built rosbridge from source at Release 2.3.0 into ~/rosbridge_ws. If you are on Jazzy and apt install comes up empty, that is the reason and building it is the fix.

What I would tell you if you are about to build one

rosbridge turns "needs ROS" into "needs a browser." For a client that only reads telemetry and calls a few services, this is a much better deal than a native ROS client, and it is the single decision that made the rest of the app simple.
A framework is not free, and canvas widgets do not need one. If most of your UI is drawn rather than laid out, the reconciliation you are paying for has nothing to reconcile.
Guard the expensive draw on visibility. The 800k-point cloud is only unaffordable when you paint it on a tab nobody is looking at.
Discovery is a feature, not a nicety. The subnet scanner took an afternoon and removed the last reason anyone needed me in the room.
Assume the built app is a different app. nodeIntegration: false plus an asar archive breaks assumptions that hold perfectly in npm start. Package early, package often.
Simulate the mission before you fly it. A Monte Carlo runner and two separate noise sources cost an afternoon; the alternative is finding out with a drone and a shelf.
Let the flight controller fly. The autonomy node publishes a position setpoint at 10 Hz and gets out of the way. ArduCopter has spent a decade learning to hold a position; a Python node over ROS will not beat it.
Draw the plan and the reality as two separate lines. They come from independent sources (the brain's waypoints and SLAM odometry), so the gap between them is the one number that tells you whether any of this is working.

This is WP2 of a 14-student project for the industry client EDISA: the ground station, the mission planner and the drone-control stack. The airframe, the SLAM tuning and the barcode/volumetry pipeline are other people's work packages, and this post only covers mine.

I'm an audio DSP and software engineering student at UPC. Most of what I build is audio plugins: this was a very enjoyable detour. More at github.com/lluisestape-upc.

Designing a 5-band parametric EQ from the biquad up, in MATLAB

Lluis Estape — Mon, 07 Sep 2026 05:27:38 +0000

A build log on a 5-band parametric equalizer written entirely in MATLAB: the filter design in detail, the pole-zero reading that tells you what a filter does before you plot it, and an honest audit of where my implementation diverges from its own UI.

Five cascaded biquads, RBJ cookbook coefficients, a live response curve, a rolling spectrogram and a pole-zero view. One classdef, no App Designer, no toolboxes beyond base MATLAB.

The design: twenty lines that contain a bilinear transform

Here is the entire filter design, verbatim:

function [b, a] = biquadCoeffs(app, i)
    wc    = 2 * pi * app.Freqs(i) / app.Fs;
    wc    = max(0.005, min(pi - 0.01, wc));
    alpha = sin(wc) / (2 * app.Qs(i));
    cosw  = cos(wc);
    switch app.Tipos{i}
        case 'Peaking'
            A = 10^(app.Gains(i) / 40);
            b = [1+alpha*A, -2*cosw, 1-alpha*A];
            a = [1+alpha/A, -2*cosw, 1-alpha/A];
        case 'High-Pass'
            b = [(1+cosw)/2, -(1+cosw), (1+cosw)/2];
            a = [1+alpha,    -2*cosw,     1-alpha  ];
        case 'Low-Pass'
            b = [(1-cosw)/2,  (1-cosw), (1-cosw)/2];
            a = [1+alpha,    -2*cosw,    1-alpha   ];
    end
end

Almost everything interesting about this project is compressed into those coefficients, so it is worth unpacking properly.

Where the bilinear transform went

These are digital filters, but nobody designs a biquad directly in the z-domain. You start from an analog prototype, in the peaking case

        s² + (A·ω0/Q)·s + ω0²
H(s) = ------------------------
        s² + (ω0/(A·Q))·s + ω0²

and map the s-plane onto the z-plane with the bilinear transform, s = (2/T)·(1−z⁻¹)/(1+z⁻¹). That map is not linear in frequency. It squeezes the entire infinite analog axis into the finite interval [0, π], according to

ω_digital = 2·arctan(ω_analog·T / 2)

which is why you prewarp: you deliberately design the analog prototype at the distorted frequency that maps back onto the digital frequency you actually wanted. Prewarping at ω0 is what makes the center frequency come out exact.

And that is the reason cos(wc) and sin(wc) appear in the code at all. If you carry the algebra through with prewarping at ω0, every tan(ω0/2) collapses into trigonometric functions of ω0 itself, and the coefficients come out in the closed form above. The trig is not a shortcut or an approximation. It is the bilinear transform, already solved.

Which also tells you what the design does not promise. Prewarping is exact at one frequency and only one. Everything else is warped, and the warping compresses hardest near Nyquist. That is measurable, and I measured it further down.

Alpha, and what Q means here

α = sin(ω0) / (2Q)

α is the only place the bandwidth enters. For the low-pass and high-pass this is the classical resonance Q: Q = 1/√2 ≈ 0.707 gives the maximally flat Butterworth response, higher Q gives a resonant peak at the corner.

One caveat worth stating precisely, because it is a common misreading: for the peaking filter, RBJ defines the bandwidth between the half-gain points (half the boost in dB), not the conventional −3 dB points. A 12 dB bell at Q = 2 has its stated bandwidth measured at 6 dB. So Q numbers are not directly comparable between a bell and a shelf, and they are not comparable between EQs unless both tell you which convention they use.

Why 10^(G/40) and not 10^(G/20)

The obvious way to turn decibels into a linear gain is 10^(G/20). The code uses forty, and the reason is a small piece of algebra that is worth doing once.

Evaluate the peaking filter on the unit circle at the center frequency, z = e^{jω0}, and factor e^{−jω0} out of the numerator:

N(ω0) = e^{−jω0} · [ (1+αA)·e^{jω0} − 2cos ω0 + (1−αA)·e^{−jω0} ]
      = e^{−jω0} · [ 2cos ω0 − 2cos ω0 + j·2αA·sin ω0 ]
      = e^{−jω0} · j·2αA·sin ω0

The cosine terms annihilate and only the imaginary part survives. The denominator is the same computation with α/A in place of αA, so almost everything cancels:

H(ω0) = (2αA·sin ω0) / (2(α/A)·sin ω0) = A²

The filter delivers A², not A, because A multiplies the numerator and divides the denominator. So to get G decibels of boost you need A² = 10^(G/20), hence A = 10^(G/40).

Verified numerically on the shipping coefficients, which is the only reason I trust the derivation rather than my memory of it:

| Slider | 20·log10|H(ω0)| |
|---|---|
| +6 dB | +6.0000 |
| −9 dB | −9.0000 |
| +12 dB | +12.0000 |

Reading the poles and zeros

This is the part I would want a student to take away, because it turns filter design from coefficient soup into something you can predict on paper.

The zeros are the filter's identity

Look at the numerators, not the denominators.

High-pass: b = (1+cos ω0)/2 · [1, −2, 1]. The polynomial 1 − 2z⁻¹ + z⁻² factors as (1 − z⁻¹)², a double zero at z = +1. On the unit circle z = 1 is DC, so the response is forced to exactly zero at 0 Hz. Not attenuated. Zero.
Low-pass: b = (1−cos ω0)/2 · [1, 2, 1], which is (1 + z⁻¹)², a double zero at z = −1, and z = −1 is Nyquist.

Both are second-order nulls, which is where the 12 dB/octave rolloff comes from: each zero contributes 6 dB/octave.

The denominators of both are identical. A low-pass and a high-pass at the same frequency and Q have exactly the same poles and differ only in where they put their zeros. That is the whole distinction.

The pole radius has a closed form

For the LP/HP denominator a = [1+α, −2cos ω0, 1−α], normalise by a(1) and use the fact that for a monic quadratic the product of the roots is the constant term. The poles are a complex conjugate pair, so their product is |p|²:

|p|² = (1 − α)/(1 + α)        ⟹        r = sqrt( (1−α)/(1+α) )

Two consequences fall straight out.

The filter is unconditionally stable. α > 0 for any positive Q, so (1−α)/(1+α) < 1, so r < 1 always. There is no Q, no frequency and no sample rate at which this design puts a pole outside the unit circle. That is a property of the form, not of your parameter clamping.

Q is pole radius. As Q → ∞, α → 0 and r → 1: the pole walks toward the unit circle and the response sharpens into a resonance. Checked against roots() on the actual coefficients at 1 kHz:

Q	α	`sqrt((1−α)/(1+α))`	`abs(roots(a))`
0.5	0.14199	0.866788	0.866788
0.7071	0.10041	0.904163	0.904163
2.0	0.03550	0.965110	0.965110
10.0	0.00710	0.992925	0.992925

Six decimal places. The formula is not an approximation.

Boost sharpens the poles, cut sharpens the zeros

The peaking filter is where this gets elegant. Its numerator carries αA and its denominator α/A, so by the same argument:

r_pole = sqrt( (1 − α/A)/(1 + α/A) )        r_zero = sqrt( (1 − αA)/(1 + αA) )

At 1 kHz, Q = 2:

Gain	pole radius	zero radius
+12 dB	0.982364	0.931511
−12 dB	0.931511	0.982364

They swap. Exactly. A boost pulls the poles toward the unit circle to build the peak; a cut pulls the zeros toward the circle to dig the notch, and leaves the poles further in.

And that symmetry is not a coincidence of these numbers. Substituting A → 1/A maps the numerator coefficients onto the denominator coefficients and vice versa, so

H_{+G}(z) · H_{−G}(z) = 1        exactly, at every frequency

The RBJ peaking filter is its own inverse. I checked it on 512 log-spaced points: the largest deviation of the product from unity was 4.6 × 10⁻¹⁶, which is floating point noise and nothing else. Boost 9 dB at 1 kHz with Q = 2, then cut 9 dB at 1 kHz with Q = 2, and you have mathematically reconstructed the input signal. Not approximately undone it.

The cascade

Five biquads in series. Two consequences, one for the audio and one for the picture.

For the audio, applyEQ runs them sequentially:

for i = 1:app.NumBands
    [b, a] = app.biquadCoeffs(i);
    b = b / a(1);  a = a / a(1);
    out = filter(b, a, out);
end

(The explicit a(1) normalisation is redundant, since filter normalises internally, but it makes the difference equation the code is implementing unambiguous. And it is worth knowing that MATLAB's filter is a transposed direct form II, which has better floating-point behaviour than the plain DF-II you would write by hand.)

For the picture, cascading LTI systems multiplies transfer functions, so updateEQ evaluates the product directly on the unit circle:

f = logspace(log10(20), log10(min(app.Fs/2 - 1, 20000)), 512);
z = exp(1j * 2*pi*f / app.Fs);
H = ones(size(f));
for i = 1:app.NumBands
    [b, a] = app.biquadCoeffs(i);
    H = H .* (b(1)+b(2).*z.^-1+b(3).*z.^-2) ./ ...
             (a(1)+a(2).*z.^-1+a(3).*z.^-2);
end
magdB = 20*log10(abs(H) + eps);

z = exp(1j·2πf/Fs) is sampling the DTFT: walking the unit circle and reading H(z) at each stop. Points are log-spaced, because the display is logarithmic in frequency and linear spacing would put hundreds of points in the top octave where nothing changes and a handful below 200 Hz where everything does.

The important structural property is that both loops call the same biquadCoeffs. The curve cannot drift away from the audio, because there is exactly one place the coefficients exist. The tempting alternative, drawing an idealised bell shape and separately writing the DSP, is how EQ displays end up lying to their users.

The POLES button does the third version of the same idea. Cascading in the coefficient domain is polynomial multiplication:

b_tot = conv(b_tot, b);
a_tot = conv(a_tot, a);

Five biquads convolve into a single 10th-order transfer function with 11 coefficients each side, and zplane(b_tot, a_tot) draws the composite. So the plot above is not five overlaid biquads, it is the one filter the audio actually passes through.

Three places the implementation does not match its own UI

Deriving the maths carefully is also how you find out where your code stops obeying it. All three of these came out of writing this post.

The frequency slider lies below 35 Hz. That clamp on line 3:

wc = max(0.005, min(pi - 0.01, wc));

is there to keep cos(ω0) away from the degenerate values at DC and Nyquist. Reasonable. But solve it for frequency at 44.1 kHz:

f_min = 0.005 · 44100 / 2π = 35.09 Hz

The slider goes down to 20 Hz, and 20 Hz maps to ω = 0.00285, well under the clamp. So every band set between 20 and 35 Hz produces an identical filter at 35.09 Hz, while the label happily reads 20 Hz. The upper clamp is harmless by comparison: π − 0.01 corresponds to 21,980 Hz, above the 20 kHz the UI allows.

The warping is visible at the top of the band, as predicted. A 12 dB bell at Q = 2, measured between its half-gain points:

f0	half-gain band	below f0	above f0
1 kHz	781 Hz to 1279 Hz	219 Hz	279 Hz
16 kHz	14579 Hz to 17212 Hz	1421 Hz	1212 Hz

At 1 kHz the bell is almost perfectly log-symmetric: f0²/f_lo = 1280 Hz against a measured 1279 Hz. At 16 kHz log symmetry would put the upper edge at 17,561 Hz and it actually lands at 17,212 Hz. The upper skirt has been pulled in by 350 Hz, squashed against Nyquist. This is the bilinear transform doing exactly what the theory says it does, and it is not a bug; it is the cost of the design, and now it has a number.

The spectrum behind the curve shares an axis but not a scale. The overlay is computed like this:

dB = dB - max(dB);          % normalise to own peak
dB = max(dB * 0.35, -25);   % compress and floor

That 0.35 is a display factor with no acoustic meaning. So the FFT fill sitting behind the response curve is on the same dB axis as the curve but is neither calibrated nor absolute; you cannot read a level off it. It is there to show spectral shape. You can watch the floor doing its work in the first screenshot: the blue fill flattens along the bottom of the plot at exactly −25 dB, and that flat line is the clamp, not the signal. The spectrogram gets the honest version, normalised to peak with a −60 dB floor and no compression.

There is a fourth issue in the same function that is subtler. The FFT is 8192 points, giving a bin spacing of Fs/N = 5.38 Hz, and it is resampled onto a 300-point log-spaced display grid with interp1(..., 'linear') in linear magnitude. That resampling is doing two opposite and equally wrong things at once:

Between 20 and 100 Hz there are about 69 display points drawn from only 14 FFT bins, so the bottom of the display is interpolation, not measurement.
Between 10 and 20 kHz there are about 30 display points point-sampling 1857 bins, so 98% of the bins are simply never read. A narrow peak that lands between two sampled bins does not appear at all.

The fix is standard and I have not done it: bin the FFT into the display bands and take the max or the RMS per band, instead of point-sampling. Point-sampling a spectrum is how analysers under-report high-frequency content.

The rendering strategy, which came out of a performance bug

The first version redrew the response the obvious way: cla, then re-plot. Every parameter change destroyed every graphics object and built new ones, and dragging a band was visibly laggy.

Every graphics object is now created once in initPlot, and afterwards only ever updated:

set(app.HEQCurve,  'YData', magdB)      % not plot(...) again
set(app.HSpecFill, 'YData', specdB)
set(app.HBandDot{i}, 'XData', f, 'YData', g)

Creating a MATLAB graphics object is expensive; updating one's YData is cheap. Same lesson as the DOM, and as ctx.fillRect versus rebuilding a canvas: the drawing was never the problem, the allocation was.

The spectrogram uses the buffer form of the same trick, a 300 × 100 circular buffer with a head index, refreshed into a single imagesc handle. New columns overwrite the oldest, nothing is reallocated and nothing scrolls.

There is also an offline path: computeFullSpectrogram() runs a proper STFT over the whole file and opens it as a 3-D surface. That one is allowed to be slow, because you asked for it explicitly and it renders once.

Three timers, and the constraint they work around

80 ms, spectrum. An 8192-point Hann-windowed FFT of the current playback window, feeding both the overlay and one new spectrogram column. One transform, two consumers.

50 ms, debounce poll. Fires restartPlayback() 150 ms after the last parameter change.

10-second chunks, playback. startChunk() processes and plays ten seconds, chaining the next from the audioplayer object's StopFcn.

The last two are one mechanism, and they exist because of a hard limit: MATLAB's audioplayer plays a buffer you hand it, and gives you no way to swap coefficients mid-buffer the way a real-time audio callback would. Changing the EQ therefore means re-filtering from the current position and restarting the player.

Chunking makes that affordable. Re-filtering a five-minute file on every knob movement is unusable; re-filtering ten seconds is instant. The 150 ms debounce stops a knob drag, which emits dozens of callbacks a second, from queuing dozens of restarts. Drag freely, and the audio catches up 150 ms after you let go.

It is scaffolding around a missing feature, but naming the constraint honestly is what produced the right structure: the buffer you can afford to recompute sets the latency you can offer.

The mouse maths

Grab a band directly on the response plot and move it. onAxesButtonDown picks the nearest band, onMouseMove maps cursor position to frequency and gain, onMouseUp clears it.

Nearest is measured in normalised log-frequency, not in pixels or hertz:

logDist = abs(log10(app.Freqs) - log10(clickF)) / (log10(20000) - log10(20));
[minD, i] = min(logDist);
if minD > 0.2, return; end

The denominator is 3 decades, so the 0.2 threshold is 0.6 decades, a factor of 3.98, almost exactly two octaves. You can grab a band from up to two octaves away and no further.

The drag mapping is logarithmic in X and linear in dB in Y, so a centimetre of mouse travel near 100 Hz changes the frequency far less than the same centimetre near 10 kHz, which is what makes it feel right. The scroll wheel adjusts Q multiplicatively, ×1.2 or ÷1.2 per tick, clamped to [0.1, 10]. Additive steps would crawl at high Q and leap at low Q; a constant ratio feels identical everywhere in the range.

Every gesture ends by calling updateEQ(), scheduleRestart() and markCustomPreset(), the last of which flips the preset dropdown to "Custom" the moment you touch anything, so the label never lies about what you are hearing.

Presets

Six built-ins plus user presets saved as .mat files into a presets/ folder created on first launch.

Each preset is a struct of Freqs, Gains, Qs and Tipos. savePreset() validates the name against the built-ins, sanitises it for the filesystem, warns on overwrite and rebuilds the dropdown. Unremarkable, and it is what makes the thing usable rather than a demo.

What MATLAB was good at, and what it was not

I write most of my audio code in C++ with JUCE, so the comparison is worth making.

The maths is the code. filter(b,a,x), conv, roots, zplane: the gap between the equation on the page and the line in the editor is nearly zero. Verifying the pole-radius formula against roots() took one line.

Inspection is free. Being able to stop, print the actual coefficient vectors, convolve the cascade by hand and check H(+G)·H(−G) = 1 in the command window is a different debugging experience from attaching a debugger to a plugin host. Every verified number in this post came out of that.

And what it was worse at is the thing the timers work around: there is no real-time audio callback. The chunking, the debouncing, the restarting are all scaffolding around that one absence. In JUCE the same feature is a coefficient update inside processBlock and nothing else.

Which is the honest summary. MATLAB is where I would design and verify a filter. It is not where I would ship one.

Takeaways

The trig in the RBJ coefficients is a solved bilinear transform. cos(ω0) and sin(ω0) are what prewarping collapses into. Knowing that tells you the center frequency is exact and everything else is warped.
A = 10^(G/40) because the peaking filter delivers A². The gain multiplies the numerator and divides the denominator.
r = sqrt((1−α)/(1+α)) is the pole radius, exactly. It proves the form is unconditionally stable and it makes Q concrete: Q is how close the pole gets to the unit circle.
Read the zeros. z = +1 is DC, z = −1 is Nyquist, and a double zero is 12 dB/octave. You can predict a filter's shape before plotting anything.
Derive your own constraints and then check them numerically. The 35 Hz clamp had been in the code for months and I found it by solving the clamp for frequency, not by listening.
Create graphics objects once, set() them forever. cla in a live update path is the performance bug.

Source is on GitHub.

I'm an audio DSP student at UPC. Most of my work is C++/JUCE (six VST3 plugins here), but this one started in MATLAB and stayed there.

Amparo: applying for food aid without reading a single word

Lluis Estape — Sun, 06 Sep 2026 00:44:08 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

Every year an enormous amount of aid money goes unclaimed. Not because it runs out, and not because nobody needs it, but because of something much stupider.

The form is the wall.

If you are blind, if you never learned to read well, or if you arrived last month and don't yet speak the language the form is printed in, the help you are entitled to is sitting behind a document you cannot fill in. You need a neighbour, a caseworker, or a volunteer to sit down with you. So you wait. Or you never apply at all.

I wanted to see if the wall could just be removed.

Amparo completes a real aid application entirely by talking. No reading. No typing. No form. It asks a few simple questions out loud, you answer in your own words in whatever language you speak, it reads back what it understood so you can catch mistakes, and it hands you a finished PDF to take to your local food bank.

The part I care most about is that it accepts answers the way people actually give them. Nobody says "household size: four". They say:

"We're me, my mum and two little kids."

Amparo works out that there are 4 people in the household, 2 of them children, and moves on. It does the paperwork thinking so the person doesn't have to.

You can also correct it at any time, about any field, however long ago you answered. Say "no, I said three, not four" and it fixes that value and carries on. That mattered more than I expected. A voice interface without a correction path is a trap, because you cannot see what it wrote down.

Demo

The moment worth watching: one messy spoken sentence, and three fields fill themselves in on the right.

Code

lluisestape-upc / Amparo

Apply for aid entirely by talking, in your own language. Voice-first accessibility tool built with Gemini + ElevenLabs.

Amparo

Apply for aid entirely by talking, in your own language.

Billions in aid go unclaimed every year, and one of the reasons is painfully simple: the form itself is the wall. If you are blind, if you don't read well or if you don't speak the language the form is written in, the help you are entitled to is out of reach.

Amparo removes the form. It asks you a few simple questions out loud, you answer in your own words in whatever language you speak, and it fills in a real aid application for you, then hands you the completed PDF.

Built for the DEV Weekend Challenge: Generosity Edition.

How it works

    you speak  ──►  Web Speech API  ──►  Gemini (the brain)  ──►  filled form
        ▲                                       │
        └────────  ElevenLabs (the voice)  ◄────┘

Gemini reads the blank form, asks about one field at a time in simple kind…

View on GitHub

MIT licensed. form_schema.py defines the one form being filled. Swap the fields there and the whole app targets a different aid program without another line changing.

How I Built It

Two models, each doing what it is genuinely good at, behind a Flask backend and a single accessible HTML page.

Google Gemini is the brain. It is not transcribing. It is conducting an interview. It reads the blank form, decides what to ask next one field at a time, and pulls structured values out of unstructured human speech. Every turn it returns strict JSON: the complete state of the form, what to say next, and which language the person is speaking.

Returning the whole form state rather than a diff is the decision that made corrections work. My first version returned only the fields learned that turn, and corrections silently failed: the model kept its earlier answer. Sending back the full state each turn removed the ambiguity entirely, because a corrected value simply replaces the old one.

ElevenLabs is the voice. eleven_multilingual_v2 speaks every question in a warm human voice, in whatever language Gemini detected. The opening greeting is spoken in several languages at once, so there is no language menu to read before you can begin. You just answer in yours, and everything follows from there.

The decisions I would defend

It reads back every value it records. The person cannot see the screen, so a value that is not spoken aloud is a value they cannot check.
Errors are spoken, never silent text. An accessibility tool that reports its failures in writing has failed twice.
When the browser cannot understand you, Gemini listens instead. Browser speech recognition is weakest on accented and hesitant speech, precisely the people this is for, which is an awkward gap for an accessibility product. So every answer is recorded alongside it, and when it gives up, the audio goes to Gemini, which transcribes it directly and answers in the same call. Recordings are re-encoded to 16 kHz mono WAV in the browser rather than trusting container support for whatever the browser happens to record.
It tells you where to take it, and it does not guess. Once the form is complete, the applicant's own address finds the nearest real food bank, which is spoken aloud and printed on the form. Those places come from OpenStreetMap, never from the model. I could have asked Gemini for nearby food banks and it would happily have answered, but sending someone who is already struggling to an address a model invented is worse than telling them nothing. When nothing is found, nothing is claimed.
Nothing is kept. Answers include income and home address. They are deleted the moment the PDF is downloaded, and abandoned sessions expire within the hour. A tool that asks vulnerable people for their address should be able to say exactly how long it keeps it.
You never lose your place. Answers survive a reload or a dropped connection, and it welcomes you back where you left off.

The interface itself translates into five languages and flips to right-to-left for Arabic, because an app that speaks your language while its buttons don't is only half accessible.

Prize Categories

Best Use of Google AI. Gemini runs the entire conversation: choosing questions, extracting structured data from natural speech, detecting the language, applying corrections to any earlier field, and transcribing the audio itself when the browser's recognition fails.

Best Use of ElevenLabs. Every word the app speaks, multilingual, including the opening greeting that lets someone choose their language without reading anything at all.

Next would be a hosted version, so it can be tried rather than watched, and more forms. The food bank intake is one wall of many, and the interesting thing about this approach is that the wall was never really about food.

How I built my own set of audio plugins with JUCE

Lluis Estape — Sat, 05 Sep 2026 12:51:47 +0000

A build log on ESP, six VST3 plugins written in C++ with JUCE 8 and shipped through a store I built myself. What the framework does for you, where it stops, and the one measurement that changed how I work.

The line

Six plugins, all JUCE 8, all VST3 plus standalone, all GPL v3, all downloadable from esp-plugin-store.vercel.app:

Plugin	What it is
Basic Oscilator	three oscillators on `juce::dsp`, the first thing I ever built, kept honestly
VERTEX	dynamic range compressor with a live transfer curve
ESP-L1	brick-wall limiter with pre and post spectrum overlay
MEGACRUSHER	distortion, saturation and bit-crusher, three algorithms
SPECTRUM	real-time analyser, 2048-point FFT, spectrogram and 3D waterfall
SYNTH/1	16-voice wavetable synth, unison, step sequencer, FX rack, interactive EQ

That table is in the order I wrote them, and the order matters more than any single plugin. Each one starts roughly where the previous one ran out of framework.

What `juce::dsp` actually hands you

Basic Oscilator is three oscillators, three LFOs, a bit-crusher and a master gain. Almost all of it is the juce::dsp module doing the work:

juce::dsp::ProcessSpec spec;
spec.maximumBlockSize = (juce::uint32) samplesPerBlock;
spec.sampleRate       = sampleRate;
spec.numChannels      = (juce::uint32) getTotalNumOutputChannels();

for (int i = 0; i < 3; ++i) {
    oscillators[i].prepare (spec);
    lfos[i].prepare (spec);
    lfos[i].initialise ([](float x) { return std::sin (x); });
}
masterGain.prepare (spec);

That is the whole contract of the module. Prepare everything with one ProcessSpec, wrap your buffer in an AudioBlock, hand it to a processor as a context:

juce::dsp::AudioBlock<float> block { tempBuffer };
oscillators[i].process (juce::dsp::ProcessContextReplacing<float> (block));

juce::dsp::Oscillator takes its waveform as a lambda, so the three waves are three one-liners:

case 0: osc.initialise ([](float x) { return std::sin (x); });                       // sine
case 1: osc.initialise ([](float x) { return x / juce::MathConstants<float>::pi; }); // saw
case 2: osc.initialise ([](float x) { return x < 0.0f ? -1.0f : 1.0f; });            // square

Two things about that code, and I am leaving both in the repo rather than quietly fixing them.

The first is a bug I can name precisely: tempBuffer.setSize(...) is called inside processBlock. That is a heap allocation on the audio thread, once per block, which is the one thing you are not allowed to do. It never caused an audible dropout on my machine at a 512-sample buffer, which is exactly why beginners keep it. The rule is not "avoid allocations because they are slow", it is "avoid them because their worst case is unbounded and your deadline is not".

The second is not a bug, it is the framework being honest about its scope. x / pi is a mathematically perfect sawtooth and a spectrally terrible one: it has infinite harmonics, and every one above Nyquist folds back into the audible band. juce::dsp::Oscillator does not band-limit and does not claim to. Everything I built afterwards is, one way or another, me finding out what that costs.

The three things every plugin inherited

Before the DSP gets interesting, the skeleton. All six share it.

AudioProcessorValueTreeState for every parameter. Automation, host state, preset save and load all arrive free, and the UI never writes a parameter directly. Even an interactive gesture goes through the tree:

apvts.getParameter (id)->setValueNotifyingHost (range.convertTo0to1 (value));

Which is why dragging a band on SYNTH/1's EQ is automation-recordable without one extra line of code.

A hard split between the two classes. The processor owns state and touches audio. The editor owns pixels and touches neither. Where they meet, they meet through atomics or a FIFO.

Nothing on the audio thread blocks, and the UI does the expensive work. In SPECTRUM and ESP-L1 the audio thread's entire visualisation job is pushing samples into a lock-free FIFO. The editor pulls from it on a timer, runs the FFT, computes the meter ballistics, and draws. On the message thread a slow frame costs a dropped frame. In processBlock it costs a dropped buffer, and a dropped buffer is a click.

Compressor and limiter: the same envelope, two different opinions

VERTEX is a compressor: gain, threshold from -60 to 0 dB, ratio 1 to 10, attack from 0.1 to 100 ms, release from 10 to 500 ms. The detector is juce::dsp::Compressor<float>, and I am not going to pretend otherwise, because it is a good demonstration of where the framework's line actually sits. It gives you a correct compressor. It gives you nothing at all for showing the user what that compressor is doing, and that turned out to be most of the work.

The transfer curve is drawn from the same threshold and ratio the audio path uses, so the picture cannot drift from the sound. That sounds obvious. It is worth stating because the tempting shortcut, drawing a nice curve and separately writing the maths, is how visualisers end up lying.

ESP-L1 is where I stopped using the built-in and wrote the detector by hand, because a limiter is a compressor with one parameter deleted and I wanted to feel which one:

releaseCoeff  = std::exp (-1.0f / (sampleRate * releaseMs / 1000.0f));
envelopeState = std::max (peak, envelopeState * releaseCoeff);
if (envelopeState > threshold)
    gainReduction = threshold / envelopeState;

There is no attack time. Attack is instantaneous, because a brick-wall limiter that takes 5 ms to react is a limiter that lets 5 ms of overshoot through, and the entire promise of the thing is that nothing gets past. Release stays smooth and exponential, because that is what stops the gain reduction from pumping.

One coefficient, one line, and the character of the processor is decided.

ESP-L1 runs two independent FFT pipelines, pre and post limiting, drawn overlaid so you can see what the limiter actually took. Two 2048-point transforms at 30 Hz would be an unpleasant thing to put anywhere near processBlock. Where they are, on the message thread behind a FIFO, they cost nothing that matters.

MEGACRUSHER: three ways to be wrong on purpose

Distortion is the one place where "mathematically incorrect" is the product.

SOFT: tanh(drive * x)              smooth, compressive, harmonics come in gradually
HARD: clamp(drive * x, -1, +1)     brick wall, sharp corners, very bright
FOLD: mirror x back into range     reflections, wildly inharmonic at high drive

Drive spans 1x to 40x and changes character rather than just level: tanh at 40x is nearly a hard clip, so SOFT and HARD converge at the top of the range and diverge completely at the bottom. FOLD never converges with anything.

Then a one-pole tilt filter for tone, a bit-depth reducer from 16 down to 2 bits (std::round(x * res) / res, the same three-line trick as in Basic Oscilator, promoted to a feature), and a dry/wet mix so all of it can be run in parallel.

All three shapers alias, of course. That is not the same admission as the synth: here the harmonics are the point, the drive is extreme, and the folding sits under a wall of intentional distortion. The honest version is that oversampling the saturator is on the list and the plugin ships without it.

SPECTRUM: one transform, four views

juce::dsp::FFT with fftOrder = 11, so 2048 points, Hann-windowed. The audio thread fills a FIFO; the editor's timer windows it, transforms it, and maps bins to a 512-point display array with logarithmic frequency scaling from 20 Hz to 20 kHz, because linear spacing puts half the pixels in the top octave where nothing interesting happens.

Two display details are doing most of the work in that screenshot. The curve is smoothed with a 5-point moving average and drawn as quadratic Beziers rather than line segments, and the display array uses peak-hold with a slow per-frame decay, so transients stay visible long enough to read instead of flashing for a single frame.

The other views cost almost nothing, because the transform has already happened and only the drawing changes:

This is the payoff of the FIFO pattern. Once the expensive thing lives on the UI side, adding a new way to look at it is a rendering problem and never a real-time one.

SYNTH/1: where the framework runs out

Sixteen voices of juce::Synthesiser, each voice holding up to 8 unison oscillators, one juce::ADSR, and one stereo juce::dsp::StateVariableTPTFilter. Per voice the chain is: unison oscillators with phase warp, constant-power panning, tanh drive, TPT filter, then ADSR times velocity.

At the processor level: LFO, voices, master gain, chorus, phaser, tempo-synced delay, 2x oversampled saturation, 3-band EQ, then reverb.

Three details from that chain that took real time to get right.

Glide uses a multiplicative smoother. juce::SmoothedValue<float, ValueSmoothingTypes::Multiplicative> on the frequency, not a linear ramp, because pitch is perceived logarithmically. A linear glide from 100 Hz to 200 Hz spends most of its time sounding like it has nearly arrived, then lurches.

Mono and Legato modes need a note stack, not a note. Releasing a key has to fall back to whichever key is still held, so the processor keeps a stack of held notes and preprocesses MIDI before the synthesiser sees it. Legato changes pitch without retriggering the ADSR, which is a separate code path, not a flag.

The sequencer is entirely lock-free. Notes, velocities, active steps, the play flag and the current step are all std::atomic, and serialised into the plugin state as a Sequencer child ValueTree. The step grid redraws from a 30 Hz timer that reads those atomics and never locks anything.

And then there is the oscillator, which was wrong for a year.

The bug: 64 harmonics is a promise you can only keep below F4

SYNTH/1's oscillator started as a wavetable doing the obvious thing: build one table per waveform holding a fixed 64 harmonics, and read it at every pitch. Better than x / pi. Not correct.

Write down when it is actually alias-free. A table holding harmonics up to 64 * f0 stays under Nyquist only while:

64 * f0 < fs/2      =>      f0 < fs/128

At 44.1 kHz that is f0 < 344.5 Hz, roughly F4. Above that note the upper partials stored in the table exceed Nyquist and fold back as inharmonic tones. Folded partials also move the wrong way: play up the keyboard and they come down to meet you.

More than half the MIDI range sits above F4. The oscillator was aliasing over most of its useful span, and I had shipped it.

Why did I not hear it? Because a saw with some filtering and reverb on it sounds like a saw, and because I had never compared it against anything correct. "It sounds fine" is not a measurement, it is the absence of one.

The rig: measure the header, not the plugin

This is the part I would recommend to anyone doing DSP, above any specific fix.

I did not measure the oscillator inside the plugin. I built analysis/: a folder that compiles WavetableOscillator.h, the exact shipping header, unmodified, against a minimal JUCE stub, renders sustained tones across the keyboard, and dumps raw float32 buffers. A Python script turns those buffers into alias-to-signal figures.

analysis/
  measure_oscillator.cpp   # renders tones, writes .f32 buffers
  juce_stub/JuceHeader.h   # just enough JUCE to compile the header standalone
  plot_oscillator.py       # FFT, harmonic mask, alias-to-signal ratio
  data/                    # legacy_82.f32, mip_82.f32, one pair per pitch
  figures/

The method per rendered tone: FFT it, mask out the bins belonging to true harmonics of f0, and sum what is left. That leftover is the aliasing, and its ratio to the signal is a single number per pitch. Sweep the pitch and you get a curve.

Nothing here needs a DAW, a plugin host, or ears. It runs in a terminal, it produces a number, and the number is either better than last time or it is not.

There is the bug, drawn. The red curve is the old oscillator: flat at about -82 dB while the 64-harmonic promise holds, then a cliff at exactly fs/128 = 344 Hz straight up to -26 dB and worse. By the top of the keyboard the aliasing is -10 dB. That is not a subtle artefact, that is a tenth of the output being wrong.

The spectra make it visceral:

At 2 kHz the old version has more energy sitting between the harmonics than on some of them.

The fix: mip-mapping, and taking the budget from the top of the band

The standard answer is mip-mapping: a bank of tables, each holding only the harmonics that are safe in its pitch range. The detail that matters is which end of the range you compute the budget for.

H(L) = floor( (fs/2) / (f_base * 2^((L+1)/M)) )      M = bands per octave

Note the L+1. The budget comes from the top of the band, not the bottom, so every fundamental inside the band is safe rather than just the lowest one. Take it from the bottom and you have rebuilt the original bug with a smaller blast radius per band.

That safety costs brightness, and the cost is exactly why kMipsPerOctave exists:

At A4 the ideal harmonic budget is floor(22050/440) = 50.
A full-octave bank would only allow 34, throwing away a third of the spectrum to stay safe at the top of the band.
Half-octave bands (kMipsPerOctave = 2) recover 48 of the ideal 50, for twice the tables and a build that still takes tens of milliseconds.

Two more changes came with it.

Continuous level selection. The fractional band position crossfades between adjacent mip levels. A hard switch changes the harmonic count by a step, and that step is plainly audible during a glide or a slow pitch LFO: the timbre flickers.

Cubic Hermite instead of linear interpolation. Linear interpolation of a 2048-point table is a triangular kernel whose frequency response leaks badly into the stopband. It acts as a gentle lowpass plus a noise floor that rises with playback rate. Four-point Catmull-Rom costs a handful of extra multiply-adds and drops that floor substantially.

The blue curve above is the result. 96 dB better at A4. 139 dB better at C8.

The part where I was wrong twice more

This is the bit I enjoyed, and the reason the measurement rig paid for itself several times over.

A 2048-point table can represent 1024 harmonics. No practical interpolator can read them. Reading a table at a fractional rate produces images at k*(N*f0) +/- n*f0, and it is the interpolation kernel that has to suppress them. Content near the table's own Nyquist has two or three samples per cycle, where the kernel has essentially no stopband left, so those images come back as a noise floor.

Measured: at 55 Hz, an uncapped budget of 389 harmonics put images at -75.5 dBc, worse than the 64-harmonic version it replaced despite being far more correct spectrally. I could identify them beyond doubt because they sat exactly at bin(N*f0) - H*bin(f0).

Capping the budget at kTableSize/8 (eight table samples per cycle of the topmost harmonic) moves that floor to -77.3 dBc. Honest accounting: that is 1.8 dB, not a fix. The real remedy is longer tables at the low mips, because the image floor is set by table length against harmonic count, not by the cap. I kept the cap because it makes the invariant explicit and costs nothing audible: it only binds below fs/2/256 = 86 Hz, where the harmonics it discards are already under -48 dB.

And it shows up in the sweep as a real regression: below 86 Hz the new oscillator is 4 dB worse than the old one. That is in the header comment, in the report, and now in this post. A rewrite that is better by 139 dB at the top and worse by 4 dB at the bottom is still a rewrite you ship, but the 4 dB does not get to quietly disappear.

The phase accumulator is double, and setFrequency takes a double. Accumulating f0/fs in float32 lets rounding error random-walk, smearing each harmonic into its neighbours. With a double accumulator, energy within +/-2 bins of the harmonic grid sits at -164 dBc. That is two double operations per sample against four Hermite evaluations already in the loop, so it is free. Similarly, a float32 Hz value lands within about 1e-4 Hz of the target: inaudible as pitch, but it leaves the tone very slightly non-periodic, and a rectangular-window spectrum shows leakage skirts at -86 dBc. The caller already holds the precise value, so there is nothing to gain by throwing it away.

And one thing that is still broken. applyWarp() (the Sync, Bend and PWM phase-warp modes) runs before the table read and still aliases. It is phase distortion, which generates content the mip level was never chosen for. Fixing it properly needs oversampling. It is documented in the header as a known limitation rather than quietly left for someone to discover.

The store

The plugins are distributed from a store I built rather than a Gumroad page: a self-contained React 18 SPA with no build step, React, ReactDOM and Babel Standalone from a CDN, and the whole application in one index.html. Each plugin gets a seeded generative waveform animation, a screenshot carousel, and a download modal with OS and format selection. Vercel deploys it on push.

It is an unusual choice and I will defend exactly one thing about it: no build step means the deployed artifact and the file I edit are the same file. For a five-page site with no dependencies beyond React, the build tooling would have been more code than the site.

Takeaways

juce::dsp is scaffolding, not a synthesiser. ProcessSpec, AudioBlock, ProcessorChain and the FFT save you weeks. The band-limiting, the detector characters and the interpolation are yours to write.
Keep the audio thread boring. Atomics, FIFOs, APVTS, and every expensive thing on the UI side. My first plugin allocates in processBlock and every one after it does not.
"It sounds fine" is the absence of a measurement. My oscillator aliased over half the keyboard for a year and sounded fine the whole time.
Build the offline rig and point it at the shipping header. A JUCE stub and a .cpp that renders tones is an afternoon of work, and it turns "I think this is better" into "96 dB at A4".
Publish the regression. The 4 dB I lost below 86 Hz is in the header comment and in this post. A fix you only report the good half of is a fix you will re-break.
Derive the constraint, do not guess it. f0 < fs/128 is two lines of algebra that would have caught this on day one.

Everything is GPL v3 and on GitHub, SYNTH/1 included, analysis/ folder and all.

I'm an audio DSP student at UPC. If you build wavetable oscillators, go and measure yours. I would like to hear what you find.

Creating sound with gestural harmony: AethericGeometry

Lluis Estape — Fri, 04 Sep 2026 10:10:45 +0000

A build log on Aetheric Geometry, a musical instrument you play with your bare hands in front of a webcam. The first half is how hand geometry becomes harmony. The second half is the seven things that were wrong with it while it sounded perfectly good.

The idea

Point a webcam at yourself. MediaPipe finds 21 landmarks per hand, and the geometry of your hands becomes the sound.

Pinch both hands to start a thread between your index fingers. Bring them together, or make a pyramid, and the thread becomes a polygon whose vertices are your fingertips. That polygon is the instrument.

Webcam frame → flip → MediaPipe → assign_hands()
  → waveform selector (5-frame debounce)
  → gesture detection (pinch, kiss, pyramid, cross, prayer, open palm)
  → state machine (IDLE / THREAD / POLYGON)
  → compute_poly_sound() → SynthEngine.set_params()
  → OpenCV render

Pure Python. No JUCE and no external synth: dsp.py implements PolyBLEP oscillators, a TPT filter and a Schroeder reverb from scratch, and sounddevice plays them. It ships as a PyInstaller executable and has a pytest suite that needs no camera, no microphone and no audio device.

Hands to geometry to sound

The whole mapping is one function, compute_poly_sound(), and it is deliberately small:

Geometry	Musical parameter	Why that axis
centroid X	pitch of the root	left to right is the obvious pitch axis
centroid Y	filter cutoff	raising your hands opens the sound
number of fingertips	number of voices in the chord	you hold up the chord you want
polygon area	reverb wet, from 6 vertices	a bigger shape is a bigger room
aspect ratio	tremolo depth, from 8 vertices	stretching wide makes it pulse
extended finger count	waveform	with a 5-frame debounce

The third row is the one the instrument is built around. Every extended fingertip is both a polygon vertex and a chord voice, so the shape you make and the chord you hear are the same object counted two ways. Open one more finger and the polygon gains a corner at the same instant the chord gains a note.

Two of the mappings are deliberately locked behind complexity. Reverb needs 6 vertices, tremolo needs 8. You cannot reach the full parameter space with a lazy gesture, which turns "more fingers" into a progression rather than a switch.

Why the ratios are `Fraction`, not `float`

The chord is built on exact just-intonation ratios above a movable root:

CHORD_RATIOS[8] = (UNISON, MAJOR_SECOND, MAJOR_THIRD, PERFECT_FOURTH,
                   PERFECT_FIFTH, MAJOR_SIXTH, HARMONIC_SEVENTH, OCTAVE)

and they are fractions.Fraction, not decimals. An earlier version stored 1.333 for the perfect fourth and 1.667 for the major sixth, which looks harmless. It is not, and the reason is the whole point of just intonation.

Against the true 4/3, storing 1.333 is an error of

1200 · log2(1.333 / (4/3)) ≈ -0.43 cents

which is inaudible as pitch. Nobody hears 0.43 cents. But just intonation does not exist to make intervals sound in tune, it exists to make partials of different voices land on exactly the same frequency so the beating between them disappears. And beating is a difference of frequencies, which is a far more sensitive measurement than pitch.

Work it out. A fourth above 220 Hz is 293.333... Hz exact and 293.26 Hz rounded. The third partial of the root sits at 660 Hz. The second partial of the fourth sits at 586.67 Hz exact and 586.52 Hz rounded. Against the root's harmonic series those two disagree by roughly 0.15 Hz, which is a slow wow with a period of about seven seconds across a sustained chord.

That is not a tuning error you hear as pitch. It is a tuning error you hear as movement, and it is precisely the artefact just intonation was chosen to remove. Storing exact fractions costs nothing, and the only rounding left in the system is one float conversion per partial at the final multiply.

Here is what those exact ratios are, measured against the equal-tempered intervals they replace:

The fifth is 1.96 cents sharp of tempered and the fourth 1.96 flat, which is why those two barely matter on a piano. The major third is 13.69 cents flat, the sixth 15.64 flat, and the harmonic seventh is 31.17 cents flat, nearly a third of a semitone. That last one is not a badly tuned minor seventh, it is a different interval: the one that appears naturally as the 7th partial, and that 12-TET has no room for.

The voicings are ordered on purpose too. Voices enter as fifth, then major third, then octave, then ninth, then harmonic seventh, then fourth, then sixth: simplest ratios first, because the simpler the ratio, the sooner its partials coincide with the root's and the more strongly the two voices fuse into one sound rather than two.

The compromise, stated plainly

The instrument is justly tuned within a chord and equal-tempered between chords: the ratios are exact, but the root they sit on is quantised to a pentatonic subset of 12-TET.

That is a real compromise and it is worth saying out loud rather than hiding. A fully just system has no single answer for what happens when the root moves, because stacking exact fifths never closes the octave. Twelve of them overshoot by the Pythagorean comma:

(3/2)¹² / 2⁷ ≈ 1.0136        about 23.5 cents

Somebody has to absorb those 23.5 cents. Choosing a fixed ratio set over a tempered root sidesteps comma drift entirely, at the cost of transposition purity. For an instrument you wave your hands at, that is the right trade.

Two more details in the pitch path.

The pitch map is exponential, not linear. f = f_lo · (f_hi/f_lo)^t over 110 Hz to 880 Hz, so a centimetre of hand travel is the same number of cents everywhere in the range. A linear map would make the bottom of the gesture range musically cramped and the top sparse.

The root is quantised to A minor pentatonic before the ratios are applied. Five notes per octave means that with your hand anywhere in the frame, the root is one of a set with no bad intervals in it. The instrument cannot be played out of key, which for a gesture instrument with the precision of a human arm is not a limitation, it is what makes it playable.

And all of that sounded fine while being full of bugs

Here is the turn.

dsp.py, tuning.py and knob.py are free of camera, audio and MediaPipe imports. The entire numeric core is importable with nothing plugged in.

That sounds like ordinary hygiene. In practice it is what let me write analysis/measure_dsp.py, a script that renders buffers from the real DSP primitives and FFTs them. Every number below comes out of it, and I can regenerate all of it with one command and no hardware.

Without that separation, checking "is my sawtooth aliasing" means opening the app, playing a note and listening. With it, it means a number. Here is what the numbers found.

Bug 1: the phase accumulator was one sample short, every block

My favourite, because it is so easy to write and so hard to hear.

The oscillator renders a block, then writes the final phase back for the next block. I wrote back the phase at the last sample, not the phase after the last sample. One sample short, every block, forever.

The left panel should be a single spike at 440 Hz. Instead the block period stamps a whole harmonic series onto it, because a periodic discontinuity at the block rate is a modulator. The right panel shows where they land: sidebands at exactly fs/N = ±86.1 Hz around the carrier, at −40 dB.

And the tuning error it causes: 3.385 cents flat. Not enough to sound out of tune on its own. Enough to be wrong against anything else, and note the irony: I had just spent all that care getting the ratios exact to fractions of a cent, on top of an oscillator that was 3.4 cents off.

phase = (phase + n_samples * inc) % 1.0    # not (n_samples - 1)

One character of arithmetic.

Bug 2: naive saw and square, aliasing at −12 dB

A naive digital sawtooth (phase * 2 - 1) has a discontinuity per cycle, and a discontinuity has infinite bandwidth. Everything above Nyquist folds back.

At 2 kHz the naive saw sits at about −12 dB alias-to-signal. A twelfth of the output is inharmonic garbage that moves the wrong way as you play up, which on an instrument built around exact ratios is an unusually expensive thing to get wrong.

PolyBLEP corrects the samples immediately around each discontinuity with a polynomial approximation of a band-limited step, and the triangle is generated by integrating the BLEP square. Across the range that buys roughly 16 dB of alias rejection.

It does not eliminate aliasing; nothing cheap does. It moves it from "obviously wrong" to "below what you will notice", for a handful of operations per sample.

Bug 3: four comb filters sharing one feedback gain

The reverb is a classic Schroeder: four damped comb filters in parallel into two allpass diffusers. Combs need different delay lengths; that is the point, it decorrelates them.

I gave all four the same feedback gain g, which seems reasonable until you write down what T60 depends on:

T60 = -3 · D / (fs · log10(g))

D is in there. The same g across four different delay lengths means four different decay times: measured, 1.12 s to 1.28 s, a 13.7 % spread. The tail does not decay, it stages. The short comb dies first, then the next, and the character of the reverb changes as it fades.

The fix inverts the relationship: take one T60 target and solve each comb's own gain from its own delay length.

Right panel: all four combs now cross −60 dB together, at the T60 you asked for, damped or not. Left panel is what I had.

Bugs 4 to 7, briefly

No allpass diffusion at all. Four combs with no diffusers are not a reverb, they are four echo trains, and on a percussive attack you hear them as four distinct repeats rather than a wash. Two allpass stages after the combs smear the echo density without touching the magnitude response. It is the difference between a delay bank and a room.

Every envelope time changed with the sample rate. The envelope stored raw one-pole coefficients, and 0.999 means one thing at 44.1 kHz and something else at 48 kHz, so attack and release changed depending on which audio device you plugged in. Store the time constant in seconds and derive the coefficient at the current rate:

coeff = math.exp(-1.0 / (tau_seconds * fs))

Every MIDI note was an octave flat. MIDI note 0 is C−1, not C0, so 12·log2(f/C0) is not a MIDI note number. Everything was consistently an octave off, which is why it sounded internally correct and only broke when the MIDI drove something else.

The triangle overshot by 85 % on every note. The triangle comes from integrating a BLEP square, integrators need an initial condition, and mine started from zero. That is only right if the note begins at exactly the phase where the triangle is zero. Start anywhere else and the integrator spends its first moments walking to where it should have started: measured, 85 % overshoot for about 16 ms on every note onset. A click on every note, which I had mentally filed as "attack character".

The seven, in one table

Defect	Measured effect
Phase written back one sample short	−3.385 cents, sidebands at ±86.1 Hz
Naive saw and square	−12 dB alias-to-signal at 2 kHz
One feedback gain shared by four combs	T60 spread 1.12 s to 1.28 s
No allpass diffusion	four bare echo trains
Envelope stored as raw coefficients	every envelope time varied with `fs`
`12·log2(f/C0)` used as a MIDI note	every note an octave flat
Triangle integrator started from zero	85 % overshoot for ~16 ms per note

Every single one of these sounded fine.

One more, since I fixed the filter at the same time: the old lowpass used exp(-2π·fc/fs), which is 2 dB out by 20 kHz. The replacement is a two-stage TPT with a prewarped coefficient g = tan(π·fc/fs), which is exactly −3 dB at the requested cutoff.

Stopping the room from playing the instrument

The instrument also takes voice commands, offline, via Vosk, in Spanish. "jarvis, ponme una onda cuadrada." This turned into its own measurement problem, for a reason I did not anticipate.

It is keyword spotting, not language understanding: a result is scanned word by word and anything in the vocabulary fires. Which means ordinary conversation in the room plays the instrument.

Four gates, each added because a measurement demanded it:

Gate	Question it answers	Measured without it
Final results only	is the utterance finished?	partials fired 11 commands in 25 s of silence
`min_level` (peak RMS)	did anyone actually speak?	room tone fired one per 45 s at high confidence
Length triage	was it meant for us?	11 commands in 40 s of ordinary room sound
`min_confidence`	which word was it?	wrong-word substitutions on noisy input

The third is the interesting one. Requiring a wake word for everything would make the instrument unplayable, because you have to be able to bark "eco" mid-performance. Requiring nothing lets the room conduct. So length decides:

Utterance	Wake word?	Result
`congela`	no	fires, short commands need no ceremony
`sube el eco`	no	fires, still short
`pues mira sube un poco mas`	no	dropped whole, despite two command words in it
`eter pillame el eco y baja treinta por ciento`	yes	parsed fully, selects reverb, lowers it 30 %

A long utterance without a wake word is discarded entirely, not scanned for the commands it happens to contain. That one rule is what made voice control usable in a room with other people in it.

Traps I could only find by probing the lexicon

A Vosk grammar can only contain words the model already knows. Anything else is silently dropped with a warning on native stderr, so your command simply never fires: no error, no clue.

The Spanish lexicon is unaccented. mas, triangulo, atras exist. más, triángulo, atrás do not. There is now a test enforcing ASCII-only Spanish keys.
The obvious technical words are missing. Neither sinusoidal nor reverb is in the Spanish model, and tremolo is in neither model. The plain words (seno, eco, temblor) are what work.
English sine is /saɪn/, not "SEE-neh". A Spanish speaker reading the word aloud produces something the English model cannot map, hence round, smooth, pure.
aether is not in the Spanish lexicon. The wake word is eter, which is.
Filler words earn their place. ponme, una, onda map to nothing, but without them in the grammar the other words of a sentence smear onto commands.

Every voice command has a keyboard equivalent, so the instrument never depends on the microphone or on Vosk being installed at all.

The HUD: 39 ms per frame, down to 5.7

A different flavour of the same lesson.

Text goes through Pillow with real TrueType faces rather than cv2.putText, because the Hershey fonts OpenCV ships are single-stroke vector outlines with no hinting or kerning, and they were the main reason the interface looked unfinished. Panels rasterise into RGBA tiles at 2× and box-filter down, which antialiases Pillow's arcs and rounded corners for free.

Doing all that from scratch every frame cost 39 ms. Four changes:

Change	Effect
Cache rasterised tiles keyed by content	most frames became a blit
Premultiply and convert RGB to BGR once at rasterise time	blit 5.9 ms to 1.4 ms
Composite with OpenCV instead of numpy expressions	SIMD, no temporaries
Split the hold panel into chrome / dial / rows tiles	turning a knob 21 ms to ~6 ms

Steady state: 5.7 ms, and 11.6 ms while a knob is turning.

One trap worth the price of admission. The effect-meter loop in draw_status_bar used key as its loop variable, which shadowed the cache key computed just above it. Tiles were stored under the wrong key and the cache never hit once. The panel looked completely correct and simply ran at full cost, forever. Only the profiler knew.

What I would take from this

Make the gesture and the harmony the same object. Fingertips are polygon vertices and chord voices at once, so there is nothing to learn twice.
Exact ratios matter for beating, not for pitch. 0.43 cents is inaudible as tuning and audible as a seven-second wow across a sustained chord.
Name your compromise. Just within the chord, tempered between chords, because the Pythagorean comma has to go somewhere.
Split your numeric core from your I/O. Not for testing purity, so you can measure it. Every number here exists because dsp.py imports nothing that needs hardware.
"It sounds fine" is not evidence. All seven bugs sounded fine, and two of them I had unconsciously reinterpreted as character.
Write the formula down. T60 = -3D/(fs·log10 g) has D in it. Reading that once would have saved the shared-gain bug.
Profile before you optimise, and read your loop variables. A 39 ms frame caused by a shadowed variable is not something you reason your way to.

Aetheric Geometry is on GitHub, PyInstaller-packaged, with analysis/measure_dsp.py reproducing every measured figure above.

It also became the engine underneath AirStems, which won the LALAL.AI Special Prize at the Musixmatch Musicathon 2026: same hands, but what they play is the separated stems of a real song.

I'm an audio DSP student at UPC. I build VST plugins and instruments you play with your hands.

How I built AirStems: remixing a song's stems with your bare hands

Lluis Estape — Thu, 03 Sep 2026 11:50:30 +0000

🏆 AirStems won the LALAL.AI Special Prize at the Musixmatch Musicathon 2026.

A build log on turning LALAL.AI's separated stems into a real-time, gesture-controlled instrument.

What AirStems is

AirStems lets you conduct and remix a real song with your bare hands in front of a webcam. Raise or fold a finger and a stem — vocals, drums, bass, other — drops in or out. Make a fist and the whole track cuts; open your hand and it all comes back. Your left hand's height opens and closes a low-pass filter, and spreading your fingers adds reverb. Everything is locked to the beat, so a drop always lands musically, and synced lyrics scroll underneath, karaoke-style.

▶ 30-second demo video

It started at the Musixmatch Musicathon and is built on top of my open-source gesture instrument, Aetheric Geometry. The idea was simple: I already had an engine that let my hands play synthesised oscillators, so what if the thing my hands played was the actual vocals, drums and bass of a real track? LALAL.AI is what turns a finished song back into those independent parts, so it became the source the whole instrument plays.

LALAL.AI published an interview about the story and the idea; this post is the technical companion — how the stems come in, how they become a real-time instrument, and the beat-sync engine that ties it together.

System overview

There are two halves, and keeping them apart is the single most important design decision in the project.

Offline preparation (runs once per song, and is allowed to touch the network):

LALAL.AI API — separates the track into stems (WAV).
Musixmatch — time-synced lyrics (line- and word-level).
Cyanite — BPM / key / mood tags.

Each writes its output to disk, indexed by the song's name:

stems/<song>/vocals.wav  drums.wav  bass.wav  other.wav
lyrics/<song>.lrc   (or .richsync.json)
analysis/<song>.json

Real-time app (runs every frame, and never touches the network):

webcam ─► MediaPipe Hands ─► gesture state ─► StemEngine (sounddevice callback) ─► speakers
                                                ▲
                            stems + beat grid, loaded into memory on song load

The live loop only ever reads local files that are already in memory. No part of a network request is on the audio path, and that separation is what keeps the instrument glitch-free while you play.

Deep dive: stem separation → a real-time instrument

This is the core of the project, so I'll spend the most time here.

Getting the stems. The LALAL.AI flow is three steps: upload the file, request a split, poll until it is done, then download the WAVs.

sid = upload(path)                        # POST /upload/  -> source id
for stem in ("vocals", "drum", "bass", "piano"):
    tid  = split(sid, stem=stem)          # POST /split/stem_separator/
    node = wait(tid)                      # poll POST /check/ until success
    download_tracks(_tracks(node), out)   # save <stem>.wav

I request each stem I want and save the result under stems/<song>/. The app is deliberately source-agnostic: it loads whatever WAVs are in that folder, so during testing I can drop in local Demucs output or files from the LALAL.AI website without changing the engine at all.

Turning files into something playable. When a song loads, every stem is read, forced to stereo, resampled to the engine's rate, and — importantly — padded so that all stems share the exact same length. That makes them sample-aligned from time zero, which is what lets me mix them sample-for-sample later.

data, sr = sf.read(path, dtype="float32", always_2d=True)
if data.shape[1] == 1:  data = np.repeat(data, 2, axis=1)   # mono -> stereo
if sr != SAMPLE_RATE:   data = resample(data, sr, SAMPLE_RATE)
...
length = max(len(a) for a in stems.values())
stems  = {k: pad_to(a, length) for k, a in stems.items()}   # align every stem

Everything is loaded fully into memory up front, so the audio callback never has to read from disk.

Which stems, and why. For this instrument, four parts is the sweet spot: vocals, drums, bass, and a fourth ("other", or piano/guitar). Four maps cleanly onto four fingers, and each part is musically meaningful on its own — muting the drums or soloing the vocal are both instantly recognisable moves.

What mattered about the stems. For a live instrument, separation cleanliness matters far more than it does in a studio mix. In a mix, a little bleed between stems is masked because you hear everything together; here, the moment you solo the vocal or fully mute the drums, any bleed is exposed. Full-bandwidth, consistent-loudness stems delivered as lossless WAV are what make muting and soloing sound convincing in real time. As a useful side effect, the separated stems sum back to roughly the original track, so I can mix at close to unity gain without dividing for headroom.

Tradeoffs and honest feedback. Separation is not instant, which is exactly why it belongs in the offline stage — you would never want to run it inside a live session. Two things would have streamlined my integration: a single call that returns all stems as one task, rather than issuing and polling a separate split per stem; and a firmer response schema, since I ended up writing defensive parsing to locate the download URLs across a couple of possible shapes. Neither is a dealbreaker. The separation quality is the part that actually makes the project possible, and that was consistently strong.

The beat-sync engine

This is the most original piece, so it gets real space. The problem it solves: if a hand gesture takes effect the instant you make it, drops and returns land at arbitrary points and it sounds sloppy. The fix is to quantise every change to the song's own beat.

On load, I run librosa's beat tracker on the drums stem (the cleanest source of a pulse) to get a grid of beat timestamps and the BPM:

tempo, beats = librosa.beat.beat_track(y=drums_mono, sr=SR, units="time")
self.beat_times = beats          # array of beat timestamps, in seconds

Then, in the audio callback, a gesture does not change the mix directly. The hands write pending gains, and those are only committed to target gains when a beat boundary falls inside the current audio block:

# does a beat land inside this block?
t0, t1  = pos / SR, (pos + frames) / SR
on_beat = np.any((self.beat_times >= t0) & (self.beat_times < t1))

# commit the hand-wanted gains on the beat (or immediately if quantize is off)
if on_beat or not quantize:
    self.target_gains = pending

So the hand decides what changes, and the beat grid decides when. A key press turns quantisation off for instant, raw control. The same beat crossing also drives a pulse value that the on-screen display flashes with — a small touch that makes the whole interface feel locked to the music.

Hand tracking → mix control

Hand tracking is MediaPipe Hands. I assign one hand as left and one as right, and map them differently.

Right hand = stems. Each finger toggles a stem by comparing the fingertip's Y position to the knuckle below it. The difficulty is jitter: right at the threshold, a finger flickers on and off. So instead of a single line, I use two margins — the finger has to clearly cross to flip, and otherwise it holds its state:

if   tip_y < pip_y - UP_MARGIN:   finger_up = True     # clearly up
elif tip_y > pip_y + DOWN_MARGIN: finger_up = False    # clearly down
# else: hold the previous state  (hysteresis removes the flicker)

Left hand = effects. Wrist height maps to the low-pass filter (lower hand, darker sound), and how open the hand is maps to reverb. Openness is measured in a scale-invariant way, as the mean fingertip-to-knuckle distance divided by palm length, so it behaves the same regardless of how far the hand is from the camera:

openness = mean(dist(tip, knuckle) for each finger) / palm_length
# roughly 0.3 for a fist, 0.9 for an open hand

Both continuous controls are smoothed with a simple exponential moving average, so they feel responsive without following the natural tremor of the hand.

Gesture map

Hand	Gesture	Controls
Right	fingers up / down	stem 1–4 in / out
Right	fist / open palm	full drop / full mix
Left	wrist height	low-pass filter (down = dark, up = open)
Left	open / close hand	reverb (open = full, fist = dry)
Keys	space · b · n	play/pause · beat-sync on/off · next song

Audio engine internals

The engine is a single sounddevice output stream with a stereo, block-based callback. This is where the audio-focused details live.

Click-free mutes. Toggling a stem instantly would click, because the gain jumps. Instead, every block ramps each stem's gain from its current value to its target across the length of the block:

for name, audio in stems.items():
    ramp = np.linspace(curr[name], target[name], frames)   # per-block gain ramp
    mix += audio[idx] * ramp[:, None]
    curr[name] = target[name]

The effects chain is reused directly from Aetheric Geometry: a first-order IIR low-pass driven by hand height, a Schroeder reverb (four comb filters) driven by hand spread, and a light tremolo. The reverb's wet level is smoothed inside the callback, so opening your hand fades the space in rather than snapping it on:

cutoff = 200.0 * (8000.0 / 200.0) ** filter_bright    # hand height -> cutoff in Hz
reverb_smooth += 0.08 * (reverb_wet - reverb_smooth)  # ease the wet level in/out

Parameters cross from the main thread to the audio thread under a short lock, copied once at the top of each callback, so a gesture update never tears a block mid-render.

What was hard

Making it feel musical rather than glitchy. The beat-sync quantiser was the single biggest change: before it, hand-driven changes sounded messy; after it, everything lands in time.
Removing gesture flicker. Raw fingertip thresholds jitter, and the two-margin hysteresis above was what made stem toggles trustworthy.
Real-time safety. The callback copies its parameters under a lock and avoids heavy allocation. The per-sample IIR and comb-reverb loops are the CPU hot path, so block size becomes the main knob for trading latency against stability on a given machine.
Keeping the network off the audio path. Doing all separation, lyrics and analysis ahead of time, and loading the stems fully into memory, is what keeps playback from ever stalling.

Links & credit

Live page: https://lluisestape-upc.github.io/AirStems/
Demo video: https://youtu.be/BnNcGabujgc
Source: https://github.com/lluisestape-upc/AirStems
The story (interview): https://www.lalal.ai/blog/how-airstems-uses-lalal-ai-api/
Built on my open-source gesture instrument Aetheric Geometry.
Stems by LALAL.AI, lyrics by Musixmatch, analysis by Cyanite.

Questions, or a gesture you think I should map next? I'd love to hear it in the comments.

Building BoardRoom on Qwen Cloud for the Global AI Hackathon Series. (Track 3: Agent Society)

Lluis Estape — Sat, 18 Jul 2026 13:01:28 +0000

I built a society of AI agents to review circuit boards. Then I tried to prove it was better, and nearly fooled myself three times.

Every hardware engineer knows the specific dread of clicking "order boards." Three weeks
and a few hundred euros later, a package arrives, and you discover you forgot a
decoupling capacitor, or your I²C bus has no pull-ups. Nothing to do but respin.

So for the Qwen Cloud hackathon I built BoardRoom: not one AI reviewer, but a
society of five — power integrity, signal integrity, connectivity/ERC, DFM & layout,
and firmware bring-up — that inspect a real KiCad project through the KiCad MCP server,
file findings that must cite tool evidence, and argue with each other under a Moderator
before signing off.

The build went fine. It's what happened when I tried to prove the society was better
than a single big agent that turned out to be the interesting part. Three separate times,
my benchmark was quietly lying in my favor. Here's each one, because I think the bugs are
more instructive than the architecture.

The setup

The measurable claim Track 3 asks for is "a demonstrable efficiency gain over
single-agent baselines." So:

Corpus: stock KiCad demo boards.
Seeding: a script injects reproducible defects with a ground-truth manifest — removed decoupling cap, swapped SDA/SCL, missing I²C pull-ups, floated enable pin, renamed power rail. One board (a pure-analog valve preamp) gets no defects, as an honesty check that nobody invents findings.
Two configs, same inputs, same token gateway: the society (five cheap specialists on qwen-flash/qwen3-vl/qwen3-coder, one qwen3-max Moderator) versus a baseline of one qwen3-max agent with all the tools and a generalist prompt.

Then I ran it. Recall: 0.00. The society caught zero of the seeded defects.

Lie #1: my agents were right, my scoring was wrong

Rather than tune anything, I dumped the actual findings. And there it was:

[critical] connectivity_erc: Hierarchical label VCC_PIC has no matching sheet pin
                             in the parent sheet, creating an unconnected rail

That's exactly the defect I'd seeded. The society found it. The scorer called it a miss.

Why? The matcher compares structured fields — affected_nets, affected_components —
and the agents had left them empty, naming the net only in the prose of the claim.

That's not a benchmark artifact. That's a product bug I'd have shipped: the report's
headline visualization — a blast-radius graph linking findings to the nets and parts they
touch — is built entirely from those fields. My centerpiece visual was silently empty
and I hadn't noticed, because I'd been reading the claims, which looked great.

The prompts already asked for those fields politely. qwen-flash ignored it. Making the
final instruction blunt ("a claim that names a net while leaving these arrays empty is
INVALID — the impact graph is built from these fields, not from your prose") took
structured coverage from 0/9 findings to 9/15, and recall from 0.00 to 0.50.

Lesson: when a model "ignores" a field, check whether anything downstream actually
depends on it. Mine did, and the benchmark found the bug my eyes didn't.

Lie #2: I'd accidentally built a strawman

Now the baseline. It scored 0.00, produced zero findings, and burned 6.8K tokens in 29
seconds. I could have shipped that. "Single agent finds nothing, society wins" — a
beautiful chart.

Except: 6.8K tokens is nothing. A generalist reviewing a whole board can't be done in
29 seconds. So I looked.

I'd named the baseline agent moderator so it would inherit the wildcard "all tools"
entry from my default allowlist. But registry.yaml overrides the moderator down to
three overview tools — because in the society, the chair doesn't do analysis. My
"single agent with all 24 tools" had been reviewing boards nearly blind.

A tool-starved baseline isn't a baseline. It's a strawman, and it's exactly the thing
a judge should nuke a submission for. Fixed: the baseline now builds its allowlist from
defaults, genuinely getting every tool. Its token use went 6.8K → 63K.

Lie #3: I was grading the baseline on handwriting

Still 0.00, but now doing real work. Fine — maybe one agent really does drown in 24
tools? That's a great narrative. I nearly wrote it.

Instead I printed its raw output:

{ "id": "B-001",
  "title": "Hierarchical label mismatch for VCC_PIC",
  "description": "...breaking connectivity.",
  "evidence_ids": ["EV-0005"] }

The baseline found the defect too. Every finding was thrown away at the schema
boundary because it wrote title/description/evidence_ids instead of
claim/evidence/recommendation.

And whose fault was that? Mine. Each specialist prompt carries a full worked JSON example
of the finding shape. The baseline prompt I'd dashed off didn't. I was measuring prompt
quality and calling it architecture.

I gave the baseline the same worked example the specialists get. I also normalized net
names in the matcher — KiCad legitimately calls the same net VCC_PIC or
/pic_sockets/VCC_PIC, and a correct answer shouldn't lose on a naming convention.

Notice the pattern: all three bugs pointed the same direction. None of them made the
society look worse. That's not coincidence — it's what motivated reasoning looks like
from the inside. You stop debugging when the number agrees with you.

What the honest numbers say

Six boards, twelve seeded defects, two independent runs per config, because LLMs are
nondeterministic and one run isn't a measurement.

	society	baseline (1× qwen3-max, all tools)
Seeded-defect recall (mean)	0.29	0.21
Cost per corpus	$0.147	$0.429
Prompt tokens	792K	312K
Findings surfaced	49–56	6–10
Hallucination rate	0.00	0.00

Read the token row and the cost row together, because that's the whole story:

The society burns 2.5× MORE tokens and costs 2.9× LESS.

Five cheap specialists doing more total work are dramatically cheaper than one
expensive generalist doing less. The win isn't "multi-agent is smarter." It's that
decomposition lets you route by role instead of by model size — you only pay
flagship prices for the one job that actually needs a flagship: adjudicating conflicts.
That number reproduced to within 2% across runs.

And the thing I'm not claiming: the society led on recall in both runs, but by exactly
one defect out of twelve. With n=2, that's noise — I watched the same config score
0.50 and 0.00 on the same board across runs. So the honest claim is "comparable, possibly
slightly better," and that's what the README says.

The most useful result is the one that makes my project look bad

Absolute recall is low for both configs — 0.21 to 0.29. I could have quietly picked
easier defects. Here's why it's low instead:

Most of the defects I seeded are invisible to every tool that exists. Removing a
decoupling cap creates an absence — no KiCad tool reports "a part that should be here
isn't." A swapped SDA/SCL is electrically valid, so ERC has nothing to say. The only
class anything reliably caught is rail-rename/floating-pin, because ERC and net listings
actually surface it.

That's not an indictment of the agents. It's a finding about EDA tooling: the reasoning
layer is now ahead of the observability layer. These models can absolutely reason about
a missing bypass cap — they just have no instrument that reports its absence. The
bottleneck isn't intelligence. It's that we never built the tool, because no human needed
one to eyeball a schematic.

I think that's the most interesting thing I learned, and it only showed up because I
reported a bad number instead of engineering around it.

What I'd tell someone starting one of these

Evidence gating works. Every finding must cite a real cached tool-call ID, and uncited claims are rejected at the boundary — not discouraged in a prompt. Hallucination rate: 0.00 across every run, both configs. Make it structural and you stop arguing with the model about honesty.
Enforce scope in code, not prose. Each specialist's tool allowlist is enforced before the call. Prompts are suggestions; allowlists are physics.
Route by role, not by size. This is where the 2.9× lives.
Debug the results that flatter you. All three of my bugs produced better numbers. If I'd stopped at the first good chart, I'd have submitted a rigged benchmark with a straight face.

One last confession: BoardRoom's negotiation engine — bounded two-round debates,
evidence-cited rulings, fully unit-tested — never fired on real data. Across the whole
corpus, no two specialists ever produced conflicting findings. Their scopes are narrow
enough that they rarely collide. The repo ships a clearly-labeled synthetic fixture to
demonstrate the viewer, and says so in the README, because the alternative is faking a
fight and calling it a demo.

That's a real limitation of the design, discovered by measuring instead of assuming. Which
is, I think, the actual point.

BoardRoom is open source (MIT): https://github.com/lluisestape-upc/boardroom — built on
Qwen models via Alibaba Cloud Model Studio, with the KiCad MCP server. Benchmark method,
raw numbers and limitations: docs/BENCHMARK.md.

DEV Community: Lluis Estape

Your LFO runs at the buffer size: auditing the control rate of my own synth

The rule I should have written down first

1. The LFO is sampled at the buffer size

2. Portamento is quantised to the host buffer

3. Cutoff is smooth, pitch is not, and the expensive one is the one I did not need

4. Two of the four warp modes are one warp mode

5. Unison at zero detune is a +9 dB knob

The small print

The five, before and after

Reproducing this

What I would take from this

My first open source contribution was a bug nobody could hear

Picking something

Reading until the bug fits in one sentence

Measuring before touching anything

Three oscillators, three different fixes

Four times I was wrong

1. I ran a subset of the tests

2. I argued with the evidence

3. I tested a stale binary

4. My test harness never reached the code

The review was the best part

The thing I almost shipped without checking

What I would tell myself

I replaced a GNN's message function with a 4-qubit quantum circuit

The idea in one sentence

Why a graph at all

What each node knows

The quantum part

Two training details that are not optional

The 50-qubit wall

What I cannot claim

What I actually took away

I built a drone Ground Control Station in Electron, using LiDAR for autonomous navigation

The problem

The architecture, and the one decision that shapes it

No framework, no bundler

Telemetry: 16 topics, one table

Two ways to get video, because one was not enough

A scan is worthless without a position

800,000 points per scan, drawn with fillRect

The brain node: what actually flies the mission

Before any of it flew: Monte Carlo

The feature I did not plan: finding the drone

Controlling the Pi from the dashboard

What I would tell you if you are about to build one

Designing a 5-band parametric EQ from the biquad up, in MATLAB

The design: twenty lines that contain a bilinear transform

Where the bilinear transform went

Alpha, and what Q means here

Why 10^(G/40) and not 10^(G/20)

Reading the poles and zeros

The zeros are the filter's identity

The pole radius has a closed form

Boost sharpens the poles, cut sharpens the zeros

The cascade

Three places the implementation does not match its own UI

The rendering strategy, which came out of a performance bug

Three timers, and the constraint they work around

The mouse maths

Presets

What MATLAB was good at, and what it was not

Takeaways

Amparo: applying for food aid without reading a single word

What I Built

Demo

Code

lluisestape-upc / Amparo

Apply for aid entirely by talking, in your own language. Voice-first accessibility tool built with Gemini + ElevenLabs.

Amparo

How it works

How I Built It

The decisions I would defend

Prize Categories

How I built my own set of audio plugins with JUCE

The line

What juce::dsp actually hands you

The three things every plugin inherited

Compressor and limiter: the same envelope, two different opinions

What `juce::dsp` actually hands you

Why the ratios are `Fraction`, not `float`