A month or so after the birth of our daughter, Sarah and I noticed that when she wasn’t snoozing or snacking, she was almost-invariably voicing her discontent. “It’s colic,” our pediatrician advised us on an early visit. It was a term I’d heard but hadn’t really internalized, so I prodded for more information.

“Usually babies cry for very specific, understandable reasons,” our doctor explained. “They have a dirty diaper, they’re uncomfortable, they’re hungry, they’re sick, they’re in pain. If you’ve checked all these things and none of them need addressing, it’s tough to tell what’s making them sad.” The doctor shrugged. “Maybe she’s upset about Trump, or the drought, or the prospect of entering the real estate market in the Bay Area. Who knows? The takeaway is that there’s not much you can do to comfort her, and so the prescription here is for you two, not her.” Our orders were to try to remain supportive and sensitive to each other, and to realize colic is a game of stamina more than anything else.

Around this time, I stumbled across a super-interesting project by an artist in New York: a miniature indoor thunder cloud that incorporated sound and light. “Holy shit, I want one,” I thought; it’d make a kickass and apropos mobile for my stormy-attituded daughter.

Interestingly, the artist provided some pretty transparent documentation about the process of building the piece, which led me to wonder if I could make one myself. I’ve often wanted an excuse to build something powered by an Arduino, but never really had an idea I felt was worth pursuing. Spurred on by a whole heap of new thoughts and emotions that come with transforming from Not A Dad into A Dad, I decided to give it a shot.

My original idea for Miramar’s cloud was to make something that could detect sound and trigger a ‘thunderstorm’. This immediately defined some requirements: I needed a way to detect sound, a way to generate sound, and a way to generate light. I considered briefly a variety of different platforms to work with (Raspberry Pi, Arduino offshoots, etc) before ultimately deciding to go the Arduino route because 1) I didn’t want to deal with long boot times and 2) I didn’t want to risk getting sidelined by a development hornet’s nest (which is to say: I wanted this project to be about building this pretty thing, not about figuring out library compatibilities and driver versions and arcane compilation issues).

After about a few weeks of coming up to speed on Arduino and the various shields and boards one can find for it on sites like Sparkfun and Adafruit, I had a rough version of the cloud innards barely up and running. I’d chosen Adafruits NeoPixels as my light source because they seemed well-documented, tidily-packaged, and easy to communicate with, and had successfully built a functioning circuit involving an Arduino Uno board, a small microphone/amp and a tiny 3w speaker. I could ‘listen’ to audio, and could trigger lights.

It turns out, though, that simply listening for ‘some sound’ is not helpful. My cloud could trigger itself not only at Miramar’s cry, but at a passing motorcycle or a garbage truck emptying the dumpster behind our apartment way too early every frigging Tuesday morning. I needed to be able to identify specific sounds.

The fancy term for this is FFT frequency spectrum analysis. Worded simply: you can run a given snippet of sound through FFT analysis and get back some number of “buckets”, where each bucket contains the amount of a particular frequency in that sound snippet. So, e.g., you can say “here’s 1 second of sound; please tell me how much of these (say) 8 frequencies exist in this sound.” (In this example, I’m asking for 8 frequency buckets.) You can then do interesting things with these ‘buckets’.

Here’s a more visual example. Using some sound-processing software called Abelton (thanks Mike), I can visualize up to 2048 frequency buckets of audio ‘heard’ by the microphone on my laptop. If I sit next to Miramar and wait for her to cry, the buckets (‘spectrum’) look like this:

On the left are low frequencies, and on the right are very high ones (nerd note: this graph is presented logarithmically). The vertical height of the graph represents “how much” of a given frequency exists in the sound the microphone currently hears. You may have seen graphs like this in old-school music visualizers like Winamp back in the day; if you’re more the visual type, RGB histograms for images are exactly this same concept, only instead of ‘amount of sound’ you’re examining ‘amount of color’.

ANYWAY. Notice the little spiky bits near the left. Those spikes went high each time Miramar breathed in and let out a cry. The graph is telling me that there’s a lot of those particular frequencies in her cry; if I could reliably identify those frequencies on my cloud, I could theoretically trigger things based only on those frequencies.

I wrote a small bit of code on the Arduino to gather a snippet of sound from the microphone, run an FFT analysis on it, and just print the result. I held the circuit near Miramar while also watching the Abelton graph on my laptop, and tried to see if I could find some correspondence between the two. The Abelton FFT offers WAY more buckets (because my latop is way more powerful than the Arduino); the Uno board only really had enough memory for about 32 buckets, which was a far coarser resolution. Nevertheless, when I held the board near Miramar when she cried, I could see some similar spiking:

The above image is sort of like a lower-resolution version of the Abelton graph above, turned on its side. At the top are low-frequency sounds; at the bottom are high frequencies. While way more coarse, I could still see a unique enough spike to reassure me that this path was promising.

Miramar’s cry fluctuates a bit. It’s a little like pressing your fingerprint onto a surface; while it’s always your fingerprint, it changes slightly based on angle of attack, how hard you press, how oily your finger is, etc. Miramar’s cry similarly fluctuates based on her breathing, whether she’s on her side or her back, etc. So I needed to come up with some sort of “average cry” fingerprint for her.

I wrote another program for the Uno that would listen to her cry, but would throw out ‘silences’ (samples where her primary buckets went low, which was when she breathed in between cries), and average the result. This is Terrific Parenting 101: get excited when your kid cries, sit next to them with a laptop tethered to a mess of cables and electronics circuitry, DO NOT attempt to comfort them or your data is invalidated. But in the end:

Totes worth it. I had a pretty decent ‘vocal fingerprint’ for Miramar.

A problem I ran into at this point was that my Arduino board could listen to audio and process the FFT, OR it could trigger lights…but it didn’t have the processing power or memory capacity to reliably do both. After a few weeks of stumbling down a path of optimizing my code, I realized that I needed to either drop down to even less FFT resolution OR explore other microprocessors that offered more memory. I had a brief adventure with the very-alluring Arduino 101 (built-in accelerometer/bluetooth, gobs of memory), but quickly ran into weird compilation problems with the board. Apparently it’s so new that people are still trying to figure out how to even make it go. I decided I didn’t want to get lost in that, and instead tried an Arduino Mega. While notably bigger in form factor, this board turned out to have plenty of memory, so much so in fact that I could request up to 64 frequency buckets with the FFT code with no problems. More = better.

With the extra memory wiggle room, I built several ‘modes’ for the cloud to run in. For “Nightlight” mode, I wrote a simple Perlin Noise implementation to cause the lights to pulse gently in interesting patterns. The cloud defaults to this mode when powered on, which I figured would be easy for nighttime diaper changes or something simple to lull Miramar to sleep.

There’s also “Breathe” mode, which is a simple sinusoidal pulse of the lights, similar to what macbooks used to do when you put them to sleep.  “Sound” mode reacts to incoming audio, either onboard via a builtin bluetooth speaker or just ambiently. My thinking was that we could either play music to Miramar via the cloud, or she could sing/talk to it to cause different parts of the cloud to react in different ways.

“Thunderstorm” mode was the most interesting to write. I wanted a mode that felt like a good Kentucky thunderstorm, with flickering lighting bolts that have different ‘lifespans’ and brightnesses, and enough time between them to make you a little unsure if the show is over yet or not. I paired the light code with sound clips of distant thunderstorms…nothing with sharp claps of thunder or anything overtly scary; more ‘white noise-y’and nonthreatening. I have a side hope that this helps Mira avoid being scared of thunderstorms later.

I added some other features to my circuit: an RF receiver with a little keychain remote to allow me to remotely switch the cloud amongst the various modes, an Arduino shield that allowed me to read MP3 files from an onboard SD card and play audio through my teensy speaker, a thermometer to detect if anything was overheating and shut the system down (safety first). As my circuit grew, I began thinking about how I needed to physically mount it inside my cloud.

I had no delusions that I’d gotten any of this stuff right so far (I mean, it worked, but I was certain I’d either need or want to change it in the future). I also strongly liked the idea that maybe someday Miramar might get curious about her cloud, and ask if we can change it to make it work in some new way. So the idea of impermanence was appealing to me.

I designed an armature of sorts to hold my circuitry, and had it laser-cut from anti-static acrylic at Ponoko. Some foundational bits of the case were permanently welded together, but I decided to use velcro to hold other panels in place, to allow me/Mira to get inside the armature if we ever need to modify anything.

The case holds my Arduino Mega, an MP3 shield, my microphone/thermometer/RF receiver, my speaker, and then some other stuff I realized I needed to use. The power provided by the Arduino board was only barely enough to run the speaker I was using, and the audio it played (clips of thunderstorms) was pretty faint and uninteresting. So I installed a separate amplifier to drive the speaker.

The hardwired speaker was useful for playing pre-determined clips of audio I’d loaded onto the onboard SD card, but I liked the idea of being  able to wirelessly send audio to the cloud as well. I explored several bluetooth speakers, but found (annoyingly) that most seem to be able to play audio via an AUX input cable, OR via bluetooth, but not both simultaneously (or, rather without needing to manually flip a switch). So if I wanted bluetooth, I needed some other way to handle it. I ultimately decided to build a cavity to house a Jambox, which was a fairly arbitrary decision on my part (I had one, it sounded great, I rarely used it for anything else). But now I needed to route power to this extra device. I also needed to power my Neopixels independently of the Arduino circuitry. To handle all this, I built in a voltage regulator, and use male-female connectors to wire everything together (again, impermanence was a priority).

Once the armature was built and working, I began thinking about the external housing for the cloud. I watched some youTube videos about vacuum-forming polystyrene plastic at home in an oven, and while I can’t say I’m totally on board with this approach, I was able to come up with a pretty dumb but roughly cloud-like shape that comfortably held the interior circuitry.

Into the top of this housing, I mounted two push-buttons: one for resetting the circuit, and the other for cycling through the various modes (in case I ever misplaced the keychain remote). I knew I didn’t want to hardwire power into the cloud: maybe I’d want to swap out the way I mounted it, maybe I would want multiple “fixtures” to hold it in case Miramar likes it and I wanted to move it around our house. I wanted something that was secure but easily-detachable, so I chose to use speaker quick-connect mounts.

The mating coupling for the quick-connect was fastened to some pretty blue fabric wire I found online.

The ‘cloud’ texture itself is hypoallergenic stuffing. Out of the bag, this is a fibrous material used for stuffing toy animals or pillows, and it pulls apart easily. It also doesn’t offer a particularly-interesting texture for diffusing light.

I spent some time researching felting, a process that basically just involves tangling the fibers of wool or other material to varying degrees of firmness. The “felt” you might buy in a hobby shop is wool or synthetic fiber that’s been tightly-compacted by needles that poke the fibers until they’re extremely tangled and firm. I tried loosely replicating this by stabbing a wad of pillow stuffing with a crappy splintery chopstick from my sushi takeout:

Felting can also be accomplished by agitating fiber in very hot water, e.g. a washing machine, to yield a different texture:

And I was able to make yet another texture by gently rolling small fistfuls of fiber between a disposable cleaning sponge and my cutting board (basically you just want to tangle the fibers, so anything with some grip seems to work). This yielded interesting, slightly-cartoony puffballs:

I ended up opting for a combination of methods, and adhered them to the plastic housing with cheap hot glue. It took me several tries of adhering and then ripping off the stuffing before I got something I liked. I’m ok with the fact that the fiber is easily-removed, again because maybe someday Mir will want to change it, and I don’t want to feel so precious about any of this that I’m unwilling to take it all apart with her (in fact, my hope is to do exactly that).

Building the mounting mechanism for the cloud was a long and winding road. I originally envisioned something that could mount to the side of Miramar’s crib, but then thought it might be nice if the cloud could be freestanding, in the event it remains interesting enough to her to outlast her crib days. So I started working on a floor lamp. I like the sort of industrial, Restoration Hardware-ish aesthetic, and Sarah likes pretty brass and copper, so I tried to meet these two in the middle.

I built a rotary power switch into a water line valve; twisting the valve produces a nice ‘click’ that cuts power to the entire cloud. The rest of the main lamp structure is made of brass pipe with brass, copper, and nickel fittings that I found at various lamp stores around town and online.

I originally built a pretty nifty base for the structure from a piece of scrap slab mango wood I had in the garage. Problematically, though, the cloud itself was weighty enough (around 2lbs or so) that it rendered the whole lamp unstable. I spent a few days being frustrated until I had the idea to write McMaster-Carr, describe my problem, and ask if they might have any heavy iron wheels I might use to stabilize the lamp. They responded that wheels have hubs, which would make them unstable when laid on their sides, but they suggested a massive iron hand wheel, which works great and looks totally awesome to me.

After several cautionary comments from friends, I wired a safety cable through the structure to take the weight of the cloud directly, rather than putting strain on power cables.

I built a second power cable that plugs directly into a power source, and hid a small USB port on the exterior of the cloud. This allows me to easily remove it from the lamp arm and plug it into my laptop, for changing around code if I need.

The first question most friends have asked when I tell them about this project is, “Well, what does Miramar think of it?” I mean, she’s a baby; sometimes it’s interesting to her, sometimes it takes a backseat to our faces, her fingers, or a poof of dust on the floor. Sometimes she’s crying too hard to even notice it. That’s all ok; this was just as much about me trying to define for myself what aspirations I have for my relationship with her. And, too, I suppose it’s about me struggling with the thought of losing my identity in the face of having a new baby, or worrying I’m going to somehow lose my curiosity for things that don’t revolve around her. The idea of creating something that someone else might find magical is something that resonates deeply with me, and my insistence on keeping everything mutable will, I hope, convey to her my belief that curiosity is important to nurture.

I really hope she wants to take this thing apart someday.