andras/schmelczer-dev
1
0
Fork 0
Code Issues Pull requests 6 Projects Releases Packages Wiki Activity Actions

Fable clean up

Browse source
This commit is contained in:
Andras Schmelczer 2026-06-11 21:35:45 +01:00
parent 3441a7e4af
commit 4ce8a4f41d
46 changed files with 642 additions and 911 deletions
Download patch file Download diff file Expand all files Collapse all files

8
src/content/work/lights-synchronized-to-music.md
View file

@ -19,10 +19,10 @@ project:
alt: RGB LED strips glowing from a music synchronization project.
---
Spring 2016. I had a Raspberry Pi, a couple of 12V RGB LED strips someone had given me, a handful of MOSFETs from an electronics kit, and zero idea what I was doing. I wired one of the MOSFETs backwards and it got hot enough to leave a small mark on the breadboard. I learned to read a datasheet, slowly, by needing one. This was the first thing I started and actually finished.
Spring 2016. I had a Raspberry Pi, a couple of 12V RGB LED strips someone had given me, a handful of MOSFETs from an electronics kit, and no idea what I was doing. I wired one of the MOSFETs backwards and it got hot enough to leave a small mark on the breadboard, which is how I learned, slowly and because I had to, to read a datasheet. This was the first thing I ever started and actually finished.
The plan was something like: play music, look at it, make the lights match. I got bands wrong first. Mapping raw audio amplitude to brightness made the lights pulse with anything (clipping, voice, fan noise), a strobing mess that hurt to look at. Reading about Fourier transforms long enough to type `numpy.fft.fft(audio_chunk)` into a REPL was the moment the project started actually behaving like the thing I'd imagined. Bass-heavy frequency bins went to red; mids to green; highs to blue. Smoothing the output over a few frames stopped the seizure-inducing flicker.
The plan was roughly: play music, look at it somehow, make the lights match. My first attempt mapped raw audio amplitude to brightness, which makes the lights pulse at everything (clipping, voices, fan noise): a strobing mess that hurt to watch. I read about Fourier transforms just long enough to type `numpy.fft.fft(audio_chunk)` into a REPL, and that was the moment the project started behaving like the thing I'd imagined. Bass-heavy bins went to red, mids to green, highs to blue, and smoothing the output over a few frames killed the flicker.
The frontend was a vanilla web page on the same Pi: pick a track, tweak the band thresholds, see what changed. No framework. Just a `<select>`, a few sliders, and an `XMLHttpRequest`. It worked.
The frontend was a vanilla web page served from the same Pi: pick a track, drag a few threshold sliders, watch the room change. A `<select>`, some sliders, an `XMLHttpRequest`. It worked.
It's not impressive in 2026. The thing I actually keep from it isn't the FFT or the MOSFETs; it's the discovery that I'd rather have a finished janky thing than an elegant unfinished one. Most of the projects on this site are downstream of that discovery; [the ATtiny85 handheld](/articles/ad-astra-attiny85-game-engine/) four years later is the same instinct with the soldering iron held steadier. I'd still recommend the same path to anyone learning: pick something physical, plug things together until they work, accept that the first version will be ugly.
None of this would impress anyone in 2026, and that's fine, because what I actually took from it wasn't the FFT or the MOSFETs. It was discovering that I'd rather have a finished janky thing than an elegant unfinished one. Most of the projects on this site are downstream of that discovery; [the ATtiny85 handheld](/articles/ad-astra-attiny85-game-engine/) four years later is the same instinct with the soldering iron held steadier. I'd still recommend the same first project to anyone: something physical, plugged together until it works, ugly on purpose.