Light Theremin

It was so hot and humid. It was also extremely crowded. There was barely enough room to turn around. And as usual, the idiots to the front and sides of me were either too high, too drunk, or too stupid to realize there wasn’t enough room to dance without stepping on or spilling beer all over the people next to them. I waited. And with my mind’s eye, I watched each bead of sweat travel from the nape of my neck and down my back. Did I mention it was hot?

It was August 1, 2003. Hundreds of us had packed into Bogart’s, a tiny little club in Cincinnati, OH, to see The Flaming Lips perform. We had endured hours of opening acts. When the Lips finally took the stage, the crowd tapped into its energy reserves. And it was amazing! What I had expected to be a plain ole rock show transformed into a carnival of blissful insanity complete with dancing animals, fake blood, giant balls, and an endless supply of confetti.

At some point during the show (I REALLY wish I could remember which song), Wayne Coyne began playing a theremin. Until that point, I had only ever seen theremins used for spooky, outer-spacey effects. A mood piece. I had never seen or heard one used to play an actual song, especially with a band. (Correction: Apparently that little whistle sound in the Beach Boys’ hit “Good Vibrations” is a theremin. I had no idea.) As Coyne’s arms and hands waved around in the air, producing sounds that crossed the line between melodic and psychotic, I was captivated.

I promised myself I’d try to play one someday. Unfortunately, this project is the closest I’ve gotten. 🙂

What The Heck Is A Theremin?


A traditional theremin looks like a box with one antenna popping out of the top and one out of the side. The thereminist (yes, that’s really what they’re called) moves their hands back and forth, away and towards the antennas. The proximity to one antenna controls the pitch of the sound that’s produced. The proximity to the other antenna controls the volume. The whole setup works by varying capacitance that controls a variable-pitch oscillator, which is really the source of all those crazy sounds.

Building a Cheap “Light Theremin”

A number of “light theremin” projects have appeared in my RSS feed over the past few years. And I had always intended to build one, but only recently did I actually get around to it. What follows is my take on the basic “light theremin”, as inspired by a version from Make Magazine.

Keep in mind that a “light theremin” is not a real theremin. Instead of varying capacitance, it varies the resistance of a photoresistor. And instead of an oscillator that produces pleasant sinusoidal sounds, it uses a 555 timer to generate square waves (PWM).

Below is the parts list and schematic if you’re interested. This project can be assembled in less than 30 minutes, if you’ve got the parts. And if you don’t have the parts, they can all be found on EBay for cheap.

Parts List

  • 1 555 Timer
  • 2 Photoresistors (Buy an assortment and try different ones)
  • 1 10 KOhm Resistor
  • 1 1 MOhm Resistor
  • 2 0.22uF Capacitors
  • 1 100uF Capacitor
  • 1 Speaker (Mine is a 30mm .5 Watt 8 Ohm speaker I found on EBay)
  • Optional: Assorted photodiodes
  • Optional: Potentiometer


The schematic calls for 6V DC. You can run it off of less. But as the voltage decreases, so does the volume.

Also, there are two photoresistors shown in the schematic. I had problems finding a photoresistor with a low enough resistance to use as an effective volume control. In the video below, I just used a potentiometer I had on hand. A photodiode might actually work better. At the time of this writing, I didn’t have any so I couldn’t try it.


If you have aspirations of building a performance instrument, you should probably look elsewhere. Light conditions vary from place to place. The response of this circuit can be unpredictable, even in the same room at different times of the day. Also, the audio produced is basically a square wave, which is the most obnoxious of all the basic oscillator types.

But if you’re looking for a fun project to do in an afternoon, this one is a lot of fun. Especially if you enjoy annoying everyone in your immediate vicinity. 🙂


Review: C4Labs’ Pi Borg Plus Enclosure

A few months ago, I picked up one of C4Labs’ Pi Borg Plus enclosures. And it’s since just been sitting in a box unopened, waiting for another RaspPi project to come along. Over the holiday weekend, I had the opportunity to dig it out and put it to use.

The Pi Borg Plus is a traditional “pack o’ cigarettes” form-factor RaspPi case. But as you can see from the photo below, it really differentiates itself in style.

The enclosure is made out of Philippine mahogany plywood, which is stained in two different shades and sandwiched together to form three layers that really create an almost organic steampunk look and feel.

The whole thing goes together pretty easily and is just as easy to disassemble should the need arise.


  • Very nice to look at
  • Provides good air circulation
  • Easy to assemble (4 pieces)
  • Provides access to commonly used ports (including MicroSD card slot)
  • Rubber feet to protect furniture
  • Works with Raspberry Pi B+, 2B, and 3


  • Price ($19.50 at the time of this writing
  • GPIO and camera connector inaccessible

It’s a great enclosure for the Pi on-the-go. If you can get past the price, I definitely recommend giving this a try for your next project.

(Note: If you go looking for the assembly instructions in the “Build” section of C4Labs’ site, for whatever reason the enclosure is called the Nucleus there.)

Hyrum’s Law

A few mornings ago, I was listening to CppCast Episode #70 on my commute into work. This particular episode featured an interview with Titus Winters. If you’re not familiar with Titus, he currently leads the C++ libraries team at Google and generally has lots to say regarding large codebases and sustainability. You can check out his CppCon talks here, here, and here.

During the interview, Titus shared a small anecdote regarding an attempt by his team to make broad code changes. They discovered weird behavioral dependencies that were never intended to be part of the API’s contract, never documented, and certainly never intended for client applications to rely upon. He followed the anecdote with the following “law”, attributed to his colleague Hyrum. (presumably Hyrum Wright)

“With a sufficient number of users of an interface, it doesn’t matter what you promised in the interface contracts, all observable behaviors of your class or function or whatnot will be depended upon by somebody.”

Titus calls this Hyrum’s Law and it’s a trueism if there ever was one.

Most developers learn to use an API or library by experimentation, regardless of whether there’s documentation to lean on. It turns out that the human brain has an uncanny need to actually apply a solution to a given problem before fully appreciating and understanding the problem. Attempting to use someone else’s software component in your own code is where the real learning starts. And when a moment of success is achieved, it’s often where the learning stops.

As I see it, there are really two major contributors to Hyrum’s Law. The first is that once some minimal amount of success is achieved, developers working with an API or library don’t always verify that a given component’s contract matches their expectations or usage. We’ve got other things to do, after all. And besides, what we’re doing makes total sense and is not at all weird, right? Umm….maybe? Maybe not? The second is that interface authors aren’t always comprehensive when it comes to contracts. Sometimes there are side-effects and pre/post conditions that escape our attention or we may make naïve assumptions about our users. For instance, threading restrictions, “undefined” behavior guarantees, object lifetime, optional vs. required client data, thrown exception types, etc. are all things that sometimes get glossed over when it comes time to document the contract. As such, users of our components can only make assumptions about things we aren’t explicit about.

As users of others’ code, we must be careful not to assume our usage of an interface is as the author intended. When in doubt (and when possible), verify. And if there’s disparity between the contract and actual behavior, please notify the author!

As authors of interfaces, we must be careful to document and make explicit the intended contract. Of course, that’s often easier said than done. It’s hard to be comprehensive, but we should give it our best shot. And we should be prepared to refine the contract at opportune times as we learn where the holes are.