P33

📖 What Pearson does

Chapter 1 is a survey of how electronic music came to be. Pearson ranges from Thaddeus Cahill’s 200-ton Telharmonium (1896), through Leon Theremin’s touch-free theremin (1920), Robert Moog’s garage-startup synthesizers (1960s), to the Ondioline, the first synthesizer that “imitated” traditional instruments (1940s). He argues — convincingly — that the synthesizer is a folk instrument: for most of its history it was homemade, garage-built, and shared among curious amateurs. Companies like Moog, Korg, and Roland only later industrialised it. He calls this out as a positive: making your own instrument expands the definition of music, and reclaims the act of construction from the corporations that own the supply chain.

The chapter is mostly prose, with three short essays:

  • Nobody trusts electronic music. Synth players used to be portrayed in films as klutzy, talentless dorks; guitar players were the suave ones.
  • Synthesizers as products. How Moog, Korg, and Roland re-branded the synth as a consumer good rather than a folk instrument.
  • The bane of learning electronics. Why getting started is so hard.
  • Our road map. Pearson’s four-part plan for the rest of the book.

🎓 Background: why our project exists

The reason this firmware exists at all is Chapter 1. Pearson’s whole project is a vote of confidence in the homemade-instrument tradition. Ours is the same vote, cast in C code instead of solder.

Two specific arguments from Pearson’s chapter are worth carrying forward, because they explain why our firmware makes the design choices it makes:

Argument 1: a synthesizer does not need to be made in a factory by professionals to be a synthesizer. Our firmware runs on a $5 microcontroller. The Teenage Engineering PO-33 K.O! — the device we are emulating — sells for about $80 and is a tiny plastic box with a custom LCD. The DSP inside the PO-33 is in many ways less capable than the AMY library we use, which is a free open-source fixed-point synth. By running AMY on the ESP32-S3 and giving it a PO-33-shaped UI on top, we are doing what the first synth-builders did: combining commodity parts into something that has its own personality.

Argument 2: products ship with their own code of conduct, which may or may not suit the end user. The real PO-33 is locked down. You cannot read its firmware. You cannot add features. You cannot change the sequencer’s resolution, or the FX order, or the chain length. You can only do what the manufacturer lets you do. Our firmware, by contrast, is MIT-licensed. Every feature you can see on the device is something you can read in the source, change, recompile, and reflash. If you think the FX order is wrong, you can change it in main/audio/amy_bridge.c. If you want 32 steps instead of 16, you can change it in main/sequencer/pattern.h.

🔧 Try it on the device

This chapter has no exercises, because there are no circuits to build. There is, however, one thing worth doing: take inventory of what you have.

Open a serial terminal and type:

> status

The firmware prints something like:

Firmware:    Ravine: Phoenix PO-33 v0.6.0
Free heap:   92 KB
Free PSRAM:  6.4 MB
Active pat:  1
BPM:         120
Volume:      3/5
Battery:     87%
Time:        14:32

That is the entire state of the device in nine lines. It is the digital equivalent of looking at a synthesizer and counting the knobs. Compare to Pearson’s how open the synthesizer used to look in 1975: no menus, no presets, no screens — just a knob and a switch per function. Our firmware has many more “functions” but the same honesty: everything you see is a knob somewhere in the source code.

Now type:

> help

and read the list. About half the verbs you’ll see in this book are listed. The other half you’ll type without prompting.

🛠 Code reference

  • The firmware that prints status — main/main.c, the shell command cmd_status(). About 40 lines; reads every global variable in the project and formats them as a single human-readable string.
  • The hardware the firmware runs on — hardware/HARDWARE.md and main/config.h. The ESP32-S3 pin map, the I²S microphone wiring, the PCM5102A DAC wiring, the TFT wiring.
  • The bootstrap story — the comment block at the top of main/main.c describes the boot sequence: hardware init → LittleFS mount → NVS open → clock init → amy_init → button scan task → display render task → sequencer timer.

🚫 What we can’t simulate

There is nothing in Pearson’s Chapter 1 that requires simulation. It is a manifesto, not a workshop. Read it; let it set the tone for the chapters that follow; then move on.