Project Description

Modeled after the “Beetbox” project found on the site ​Scott Made This​, our project was
essentially a drum machine that used touch sensors stuck into raw potatoes as the physical drums
and snares. To accomplish this, we had to use a MPR121 capacitive touch sensor breakout board,
which acted as an I2C connection between the Raspberry Pi and our individual touch sensors.
We used seven different touch sensors to simulate different drum components mainly: kick,
snare, clap, cymbal, closed, and open. The seventh sensor was reserved as a sort of beat-switch,
as it would change from drum to animal sounds when touched. These sensors were all separately
connected to the touch board, which was itself connected with the raspberry pi. To test whether
the “drums” were working as intended, we used a bluetooth speaker and headphones for sound
playback.

The physical structure of the project can be seen in this

schematic provided by the original source. The top most pins
would be fed to the actual potatoes.

Required Equipment

- MPR121 Capacitive Touch Sensor Breakout Board sold

at ​Amazon for $13.90​ or ​Adafruit for $7.95
- Soldering equipment for breakout board
- Around twelve Male-to-Female wires
- Seven potatoes
- Bluetooth/aux-connectible speaker

Required Code

- Beetbox source code

- MPR121 code

How It Works

As mentioned before, we modeled our potato drum machine

after the “Beetbox” project found on ​Scott Made This ​and
modified his code to add a beat-switch-dedicated potato. Before getting into our modifications
however, it is best to understand the original first.

The way the original Beetbox worked was by establishing an I2C connection with the touch
board and using the MPR121 class, which basically continuously monitored for touch on any one
of the seven sensors and triggered sound playback upon detection. When the MPR121 class
detected touch, the program would play its respective sound, which was handled by Pygame, a
set of Python modules normally used for game development. These sounds, whether they be the
drum kicks or animal sounds, were all stored on a directory and then assigned to a variable in the
python script.
This could be seen starting from line 29 of the original source code:

As seen in the lines after the variables were declared, each sound was also given its respective
volume.

To keep track of what sensor was touched, an array called “touches” was created of size equal to
the number of pins being used. In the source code, the array size and values were explicitly
declared (​touches ​=​ [​0​,​0​,​0​,​0​,​0​,​0​]​;​).

The program would then enter an infinite loop that would read and react to any touches detected
from any of the seven pins. This was done through simple if-then conditional checks.
If, say, pin number 3 was touched for example, the program would first check its corresponding
value from the touches array. If the value was 0, the program would print: “Pin 3 was just
touched” and would play whatever sound belonged to the pin. Its value in the touches array
would then be set to 1 until the sensor was released. Upon release, the program would also print:
“Pin 3 was just released”. Because this is a drum machine, the pins were not held for very long,
so a flurry of touch and release messages were constantly shown on the screen.

In our modified program, the last pin was designated as a beat switch pin, which, when touched,
would set off a boolean flag that would sort of invert the sounds into animal sounds. The kick
sound would turn into a dog barking, the snare into a cow mooing, and so on. Each of these
sounds were also declared and given a volume as seen in the code above.

Reflection & Struggles

Overall, we did not have too many issues. The hardware aspect our project was relatively simple.
However, we did have issues where a certain pin would continuously read as being touched
when, in fact, it had not been. This was perhaps most troubling when it happened to the beat
switch pin, as it would invert the sounds at random intervals, thus making it harder to test. There
was also an issue of finding the best placement to stick the pins into the potato, as certain areas
would be more receptive to touch than others.

The source code was somewhat messy and bloated with redundant checks, which made it
somewhat difficult to debug our beat switch code. There was definitely some confusion when
initially reading through the code as certain lines seemed unclear. The MPR121 Class
specifically, was, and to be honest still is, the most confusing part of the code. The first fifty lines
or so of the code for example, consist of global variables being initialized to various hex values.
From my understanding however, the MPR121 class acts as a sort of translator between the
sensors and the pi.

If I could have any additions to our project, I would have liked to have added another pin
dedicated to playing a continuous beat, or perhaps having some sort of “loop pin” which would
would save sequences of sounds in respect to the sensors touched and would play them back
upon being touched again. A volume pin would have also been a welcome addition, and would
not have been too hard to implement. Originally, we considered adding LEDs that would light up
upon having a certain pin touched; that would have been a cool addition as well.

All in all, I think we worked well as a group as we all had different things to bring to the table.
Laurel for example, had prior experience working with electrical components from physics class.
I thoroughly enjoyed working on this project and hope to have more experience working with
similar material in the future, either academically or casually.