Built a DIY synth for my daughter

You know how sometimes you start a little side project, something totally different from your day job, and it just grabs you? That's what happened to me a few months back. My daughter, Lily, who's six, has been really into music lately, always banging on toy keyboards, trying to make her own tunes. You know how kids are!

Around that time, I saw a 'Show HN' post pop up on HackerNews. Someone had built a synth for their kid, and I thought, "Hold on, I could totally do something similar. Maybe even make it just right for Lily." That little spark turned into a proper deep dive into how computers talk to hardware and make sound in real-time. It was way beyond my usual JavaScript and Go stuff!

The Idea and My First Stumble

Lily needed something simple, something she could touch, and most importantly, something instant. No waiting for it to turn on, no complicated menus. Just plug it in and play. My first idea, probably a common one for us full-stack devs when we mess with hardware, was to grab an old Raspberry Pi 4 I had lying around.

"Just install the regular Raspberry Pi OS with the desktop, throw a few Python libraries at it, maybe even a basic VST, and boom, synth!" I figured. It felt like the easy way out.

Boy, was I wrong. Within an hour of setting it up, I hit the first wall. The boot time for the full desktop OS was around 30-40 seconds. For a six-year-old, that's an eternity. Then came the audio delay. Trying to play notes through the standard headphone jack, even with PyAudio, felt super sluggish. We were looking at a noticeable delay, probably around half a second, which is terrible for a musical instrument. It sounded more like a broken echo chamber than a synth. I quickly learned that user experience, even for just one user, really depends on these tiny details.

Stripping Back to What Actually Worked

Clearly, the 'just throw a desktop at it' approach wasn't going to cut it. My tech lead, if this were a work project, would've definitely called out the over-engineering. I needed a really basic, super-fast setup.

My breakthrough came when I decided to ditch the desktop entirely and go with Raspberry Pi OS Lite. This immediately cut the boot time down to a much better 10-12 seconds. Still not instant, but a huge improvement.

Next, the audio. Honestly, this part is tricky. I knew the Pi's built-in audio isn't great for quick, good-quality sound. After some digging, I decided on a dedicated audio HAT (which just means 'Hardware Attached on Top'). I picked up a Pimoroni Pirate Audio Line-out HAT for about £20. This little board connects directly to the Pi's GPIO pins (these are like general-purpose input/output pins) and gives you much better audio hardware.

I then started experimenting with audio libraries in Python. My first attempts with raw ALSA (a low-level audio system) stuff were a bit messy. I kept getting ALSA: device not found errors until I realised the HAT needed specific driver setup in /boot/config.txt. Took me forever to figure out! After debugging for 3 hours one Saturday morning, it finally clicked. The dtparam=audio=on line needed to be replaced with the specific HAT overlay, like dtoverlay=hifiberry-dac. This felt similar to when our API started timing out at 2 AM because of a tiny misconfiguration in a Nginx proxy – sometimes, it's the infrastructure, not the code.

For the actual audio generation, I settled on sounddevice combined with numpy. sounddevice gives you a nice, Python-friendly way to use PortAudio, letting you do quick audio input and output with special functions called 'callbacks'. numpy is super important for making sound waves efficiently, so you don't get slow Python loops.

Here’s a simplified snippet of how I got a basic sine wave oscillator going:

import numpy as np
import sounddevice as sd

# Audio parameters
SAMPLERATE = 44100  # samples per second
BLOCKSIZE = 0       # Let sounddevice choose optimal block size
CHANNELS = 1        # Mono output

# Synth parameters
frequency = 440.0   # A4 note
duration = 0.5      # seconds
current_phase = 0.0 # Keep track of phase for continuous waves

def callback(outdata, frames, time, status):
    global current_phase
    if status:
        print(status)

    # Generate time vector for this block
    t = (np.arange(frames) + current_phase / (2 * np.pi * frequency)) / SAMPLERATE

    # Generate sine wave
    amplitude = 0.5
    outdata[:] = (amplitude * np.sin(2 * np.pi * frequency * t)).reshape(-1, CHANNELS)

    # Update phase for next block
    current_phase = (current_phase + 2 * np.pi * frequency * frames / SAMPLERATE) % (2 * np.pi)

# Start the audio stream
with sd.OutputStream(samplerate=SAMPLERATE, blocksize=BLOCKSIZE, channels=CHANNELS,
                     callback=callback):
    print(f"Playing sine wave at {frequency} Hz. Press Enter to stop...")
    input()

print("Synth stopped.")

This callback function is where the magic happens. sounddevice calls it again and again whenever the audio buffer needs filling. Using numpy here is crucial; trying to make frames samples one by one in a Python loop would mean the audio would break up and sound horrible. Doing these operations all at once (called 'vectorising') made a massive difference, cutting CPU usage from 80% with slow loops down to a steady 15-20% when playing a single sound at 44.1kHz. It's a bit like optimising a database query – you try to do the heavy lifting in the most efficient way possible, often by offloading to C-optimised libraries, which numpy does beautifully.

Wiring Up Controls and Dealing with Gotchas

For input, Lily needed actual buttons, not a touch screen. I used simple clicky switches connected to the Pi's GPIO pins. To read these, I needed the RPi.GPIO library.

One of my biggest mistakes initially was not handling button 'debouncing'. You know what's weird? Every time Lily pressed a button, it registered multiple presses because of tiny electrical noise. This meant a single press would play three or four notes rapidly, which sounded awful. In code review, we caught a similar issue in a client-side form where a user could double-click and send duplicate requests – same problem, different stack. I set up a simple software trick, waiting a few milliseconds after a button changed state before I called it a real press. This fix prevented 3 critical bugs in Lily's synth, turning crazy behaviour into smooth, reliable input.

Oh, and another gotcha was power. The Raspberry Pi 4, especially with a HAT and external buttons, can draw a fair bit of current. Using a cheap phone charger resulted in random crashes or audio glitches. Switched to a proper 3A power supply, and the stability issues vanished. This reminded me of a time our backend was slow, and we kept blaming the code, only to realise the underlying infrastructure (VM resource limits) was the real bottleneck. Sometimes, it's not the code, it's the current.

The Results and Lessons Learned

After about two weeks of evening and weekend work, including a couple of late nights where I was troubleshooting ALSA configs until 1 AM, the synth was finally stable. The audio delay was now around 50ms, which is perfectly fine for a simple instrument you can play. It was a proper polyphonic synth (meaning it could play multiple notes at once) with a few different waveforms (sine, square, saw) and an octave switch, all controlled by big, colourful buttons.

Seeing Lily play with it, making her own sounds, was incredibly rewarding. The project has been stable for about eight months now, and she still uses it regularly. This personal project also taught me some important things about building stuff:

For anyone else thinking of jumping into a DIY hardware project, especially one where timing is crucial:

* Start with the main thing. Get one note playing reliably before you worry about octaves or fancy effects.

* Don't shy away from dedicated hardware. Sometimes, £20 for a HAT saves days of software headaches.

Test rigorously. What works fine for a few minutes might crackle after an hour. Test with Node 20.9.0, Python 3.9, or whatever you're using, but also test the environment* itself.

It was a fantastic journey, reminding me that the basic ways we solve problems, make things faster, and build things step-by-step apply whether you're building a massive website or a tiny synth for your daughter. And honestly, the joy of seeing her create music with something I built myself? Priceless. It’s these kinds of projects that really make you feel like a craftsperson, not just a coder. This project, much like my Zig Journey Building a Fast Search Component, showed me the power of really digging deep into performance and low-level control when needed, even if it's for something as simple as a child's toy.

Oh, and the total cost for the components (Pi, HAT, buttons, wires, case) came to about £100. Worth every penny.