Marble Sequencer

Electronic Music Instrument Design

Dr. Paul Lehrman

Fall 2022

By: Anna Quiros, Fo Apostolo, and Alex Dumontheil

See Full Report Here

Our goal was to create a musical controller that allows users to place colored marbles in slots to trigger different notes, then to loop those notes to create songs. This sequencer establishes a simple, interactive way to compose and perform a three-layered piece, allowing for a bassline, a harmony, and a melody.

VIDEO OVERVIEW

HOW IT WORKS:

START

When the green START/STOP button is pressed, the Marble Sequencer reads through each slot sequentially.

2. PLACE MARBLES:

There are 8 marble slots, allowing the user to create two, 4/4 measures. A note is triggered when a marble is placed over a sensor. There are five different color marbles (green, red, blue, yellow, and white), each creating a unique note. The absence of a marble creates no sound.

3. CHANGE INSTRUMENT:

The 10-position switch allows the user to change the type of sound being played (i.e. the sampled instrument). Each loop layer can have its own instrument sound.

4. CHANGE TEMPO:

The sequence tempo can be designated by the user through the tempo potentiometer.

5. ADD LOOPS:

The red “loop” button allows the user to iterate through three layered loops of notes. Each loop layer has a different set of notes for the marbles, to allow for more unique layers.

TOP VIEW

INTERIOR VIEW

BOTTOM VIEW

The Build

The sensor holders were constructed out of 3D printed PLA material and were the most difficult to design. The goal was to form the holder around the sensor so it would cradle the sensor securely in place, even if the structure was turned upside down. This required several measurements and prototyping iterations (examples shown above).

The holders consist of the “cup” that contains the sensor body, two arms that reach up and connect to the top plate using epoxy, and a slot in the bottom of the cup that allows the pins to pass through. The arms of the sensor holders had to be the correct length, so that the color of the marble could be detected by the RGB sensor. After extensive testing, we decided to use the holders with the 2.5mm arms, as they were able to get the most accurate, consistent readings from the sensors.

The Electronic Bits

The Multiplexer Problem

We used eight identical Adafruit TCS34725 RGB color sensors, which unfortunately meant that they all had the same system addresses. Therefore, when we tried to connect all eight RGB sensors to the same Arduino, using the same SCL (serial clock) and SDA (serial data) Arduino pins, the Arduino was not able to differentiate between the sensors and did not output useful data.

We therefore had to end up using a Multiplexer. This device includes multiple SCL and SDA pins, allowing us to connect and use multiple sensors with the same address.

Connections to potentiometer, buttons, and 10-position switch (left to right).

Wiring of the Sensors

The wiring of the sensors was relatively simple. Each RGB color sensor connected to a unique SDA-SCL number pair on the multiplexer, 3.3V, and ground. The buttons, the linear potentiometer, and the 10-position multi-switch were connected to 5V and either analog or digital pins on the Arduino. The potentiometer was read by an analog digital input pin, the buttons were read by digital input pins, and the multiposition switch was read by analog input pins. The two buttons also utilized the internal pull-up resistors of the Arduino.

Arduino Code & Max Patch

Arduino Code

The Arduino code first initializes all the sensors and buttons at the beginning of the code by defining which pins on the Arduino they are connected to. Then, it reads values from the multi-position switch (determining location 0 through 9), the potentiometer (value between 0 and 1023), and the buttons (0 for off and 1 for pressed).

Next, the sensors take RGB readings, and the code determines the color based on the RGB values. The colors are outputted as numbers: red is 1, green is 2, blue is 3, 4 is yellow, 5, is white, and no color is -1. The data is then packaged up into a series of numbers, like the example given below:

Finally, these output values are sent out the serial port and can be read by the Max patch.

Max Patch

The final Max patch went through several iterations before landing on this final version. Our code in Max allowed for inputs to be taken from each of the sensors, and lights to be turned on in a matrix to store that data. In the matrix, each of the eight marble slots (columns) had five color options (rows). A metronome sent ticks to increment the code through each of the columns of the matrix. When a marble color was “read”, the corresponding MIDI note would be played. Different sets of notes were played for different loops. The code also took in data from the start/stop button, to begin and terminate the sequencing process, the loop button, to switch between the different loop layers, the 10-position switch, to change instrument sounds, and the linear potentiometer, to change sequencer tempo.

Reason Rack

In general, we prioritized implementing the sensors and translating physical actions to MIDI data and sound, above creating complex Reason patches. In the end, though, we ended up using ten unique sounds. Our goal was to give the user several different types of sounds to play with and to layer.

The sounds include a range of different sounds—some have hard, distinct attacks and notes (like the Bassoon), and some are softer and have a longer release time (like Geiger Pad). There were two drum kits: Pop Kit 2 and Baile Funk 1. The Electric Flute was also notable, as there was a delay on the reverb.

DISCUSSION

The two main frustrations of this project were the Arduino-to-Max patch and the color sensors. We were in flux, for a while, when we didn’t know when the Arduino-to-Max patch would start working. And, even when it did for other groups, it didn’t work for us. (We later found out that there was a specific order in which the Arduino, Max, and Reason programs had to be opened.) The color sensors, on the other hand, were just finicky . For the first half of this project, their readings were inconsistent, and it was difficult for multiple people to collaborate on them at one time, since a lot of the debugging process was just making changes to the code.

The second iteration of this project went much more smoothly than the first. We ran into fewer issues, and the experience that we gained from the first part of the project helped us debug the problems that we ran into during the second half. For example, the messy wiring inside the Marble Sequencer made the debugging process in the first half quite difficult, as it was hard to trace back wires, and connections would frequently become unplugged. However, in this final version, we had much better wire management and soldered more to secure the connections in place.

NEXT STEPS

Design and User Interface

Expand and redesign instrument to include more slots for marbles (ideally four, 4/4 measures, so 16 different slots)
Add LEDs that turn on to indicate which sensor is currently being read
Figure out how to better indicate which instrument is currently selected and which loop layer is currently selected

Electronics

Calibrate color sensors for more colors (ideally 12 total, for an entire western scale)
Continue to organize internal wiring & solder wires. While we improved our internal wire organization in this second iteration of the Marble Sequencer, we still had several connections using jumper wires that could easily disconnect. In our next prototype, we would like to continue upgrading the internal wiring and using more soldered protoboards.

Max / Arduino

Better implement the incoming data controls in Max. How can we avoid continually sending “clear” and “on” messages to the matrix?
In the first iteration, we had an option where we could store different melodies and recall them from storage. How can we again implement this? Can we add an additional control panel to allow users to store and recall melodies?
Add more matrices to allow for more loop layers
Allow user to go back and forth between matrices, instead of only linearly in one direction
Add functionality so user can choose when new data is being uploaded into each matrix, instead of it updating immediately when selected

Page updated

Google Sites

Report abuse