Hi! This is a set of stream-of-conciousness documentation I’ve done as I worked through (and continue after the class to work through) designing and building a prototyped drum machine project as culmination of the class. I’ve built a basic drum machine - it records beats and it plays back recorded beats - a simple automaton. It combines a slew of skills from the class: on the electronics side (hardware, software), ATtiny45s read and write signals along a serial bus to a raspberry pi, which on the one hand manages the machine’s logic (states, synchronization) and on the other hand does all the audio (codec, amplification through a breakout board). The best source to understand this is the source code. On the non-electronics side, I built sensors (molding and casting), housing for the sensors (3D printing), as well as a form factor for the whole thing (laser cutting). There is a ton that can be iterated on and improved, as well as things that could or should be done differently. Still, for a minimum viable product, I simply have to swap out the sensors to add responsiveness and robustness when I’m whacking at this with a drum stick. This was an awesome first deep dive in digital fab!

Bill of materials (BOM):

Quick reference

Concept:

I’m interested in combining digital fab and drumming. When I started out, I spent some time researching lasers and laser sensing. I was thinking of trying to project a drum pad onto a surface that could be customized to have a few different kits, i.e.

A few of the teaching fellows (and Neil) suggested I start with simpler input devices, and so I’ve switched focus slightly and have some sense of the form factor I want to continue with. I started out thinking towards bucket drumming, an urban art form requiring only a few five-gallon buckets :) I wanted to build a drum kit i.e. an electronic drum kit from a few 5 gallon buckets and have them each hold recorded drum sounds. Some time after, I switched again into replicating something like a roland 808, building that something would record beats and play back recorded beats to the user.

Roadmap:

After a sit-down with Brian, I’ve worked out a simple strategy for design.

  • buckets have an input board, which takes input from a sensor / force sensor and sends output of 1. which bucket 2. how hard bucket was struck
  • the signals are all sent to the main / master board or to an intermediary input board that routes the signal on if I’m worried about port / pin capacity
  • this board is responsible for sending a signal to output. So a few things have to happen here. I have to read from an SD card, the signal has to be transformed by a MP3 coder/decoder, amplified, and sent to speaker

Electronics:

  • Inputs
    • On the input side of things, I’ll test out piezo sensing (this relies on charge that accumulates in solids like crystals and ceramics as a result of applied stress) - seems like this is the approach in electronic drums especially - and step response sensing (see Neil’s).
    • What else? “nice to have” but not “need to have”… add a button or buttons to shuffle the MP3s being triggered by each bucket
  • Outputs:
    • On the output side of things, I’ll try to start simply and improve iteratively:
      • without MP3 aka beep-boop board: adapt hello, world speaker to output a sound of a specified frequency
      • with MP3:
        • raspberry pi + raspberry pi amplifier daughter board / shield (here)
        • arduino + arduino shield for MP3 codec w/ SD reader + amplifier (here
        • fab it all from scratch (this is what Matt did, seems like copied the data sheet for the codec)

Form factor

–

Documentation

  • I’ve started with electronics. To stay simple, I want to have sensor boards along a bus. A raspberry pi is the signal recipient. In simplest case for code, sensor boards take turns one and only one at a time on the bus and send readings to the raspberry pi, which does a threshold test and spits out a drum sound.
  • inputs
    • talked to Jim about async RS-like bus vs. sync I2C bus or SPI bus, asynch seems like what I want to do but I haven’t written the code to see whether this works
    • building sensor boards to work with step-response sensing + piezo sensing
    • basically what I want is serial bus board + step response sensor board with some adjustments - what’s happening here?
      • attention to power (power supply) by situation
        • connecting several boards to the raspberry pi (i.e. when it’s working) - thought rpi had a 3.3V restriction but that’s not what it looks like on the pinout in particular
        • connecting single board to my mac (i.e. when it’s not working) - doing this through ftdi so I can see the sensor in something like term.py
      • 2x2 header for bus
        • reusing PB0 for tx, PB1 for rx
      • 2x2 header for sensor - should work with step response, should also work with piezo
        • using PB3, PB4 for tx, rx
      • oh should’ve use 2x3 as 2x2 bus
"bucket banging" not "bit banging" (this joke fell flat to fellow fabbers today)


~debugging bus races~
~CLI to run the raspberry pi~

Form factor

  • sensors, housing for the sensors
    • this was the trickiest area - building a reasonably responsive sensor
    • I started with and stuck with the step-response sensor from class. The challenge I confronted was that, as is clear in the source code, the sensors are tuned to a “baseline” at the start, but after any disturbance or depression to the tx copper pad and rx copper pad, they would not return to their starting state. I tried a few fixes, among them embedding foam between the tx and the rx for its elasticity
    • This is an easily evident area to return to

In its final form:

When I return to campus, I want to swap out the current sensors with something robuster.

A big thanks to Rob and Brian for help along the way.