Stringless Bass
Introduction
My colleague and I were tasked with developing a "stringless string bass," building upon a previous student project. Through multiple iterations, user research, and alpha testing, we created an Arduino-based musical instrument that simulates the experience of playing a real string bass. This instrument employs a 9-DOF motion sensor, magnetometer, and touch sensors to replicate the physical gestures and motions involved in playing, providing a realistic and innovative synthesizer experience without the use of traditional strings.
Timeline: 2 months
Collaborators: Marley Macarewich
Overview
Our synthesizer mimics the action of an acoustic contrabass through two main sensors: a touch-sensitive potentiometer to read the position of the user’s fingers along the neck and a motion sensor (IMU) that reads the position and velocity of the bow.
The bow is equipped with 4 sets of LEDs that inform the user of which “string”—either E1, A1, D2, or G2—they are on based on the angle of the bow. Our code then reads the location of the fingers on the fingerboard and maps it to the note that would be played based on that finger position on a real contrabass.
Finally, the user moves the bow in the air to produce sound from the instrument, where loudness is determined by the speed at which the bow is moving.
Design
We designed an initial barebones electronic prototype, hand soldering the electronics to a solderable breadboard. Our enclosure was primarily made through laser cutting, with a “sandwich” design using 3 layers of 0.5” plywood.
To increase the aesthetics and user-friendliness of the instrument, we decided to change our housing to acrylic and edge-light the entire main body, adding features like a detachable bow cable, built in bow-holder, and ergonomic button placement.
Our final product consisted of two custom-made printed circuit boards (PCBs) embedded in a large acrylic enclosure. The PCB in the main body of the instrument housed the microcontroller, logic level converter, and primary LED strip along with all resistors and capacitors needed for our circuits — we didn’t have the budget for surface mount devices :(
This PCB was then connected to the PCB in the bow by a detachable ethernet cable. The bow housed LEDs, a motion sensor, and a pushbutton.
Software
To avoid the issue of gimbal lock, we decided that the optimal method for detecting bow angle was through quaternions (which mathematically remind me of the quantum momentum operators!).
We also implemented a complimentary filter for our calculation of velocity. Since velocity can only be calculated by a rough integration of acceleration data, software filtering algorithms were required to eliminate drift over time.
We designed and ran a calibration procedure on each of our prototypes to linearize the distance per unit of resistance for our touch-sensitive potentiometers. With these linear values, we could then calculate finger position and translate this to the note that would be played on a real contrabass using the equation freq=c/2L.
Combining these inputs, one loop of our code would read the position of the bow to set our frequency to E, A, D, or G, then read the finger position to calculate what note should be played, then read the speed of the bow to determine the loudness of the note.
Unexpected Challenges
Unfortunately, a month into the project, we were affected quite drastically by the chip shortage. Our microcontroller, the Teensy 3.2, went completely out of stock along with our choice of motion controller.
We decided to switch to the Teensy 4.0 and use a different motion controller that lacked many of the features we relied on, but this came with a slew of other issues. Since the Teensy 4.0 had no Digital to Audio Converter built in, we had to use a chip shield that would break out this functionality - we ended up completely redesign our housing to accommodate this extra thickness.
Additionally, the change of motion sensor meant we had to rebuild our entire motion control code base, as the new chip’s built-in X, Y, and Z axes were swapped. Its lack of internal processing meant that we had to rewrite many functions from scratch and recalculate the values of our quaternions.
Beyond these issues, we had to deal with multiple versions, where one round of prototypes could have up to 4 combinations of chip/IMU. We created much more robust code that automatically detects which combination is in the unit and runs the appropriate forks of code.
Research and Testing
We distributed our instrument prototypes for testing with targeted groups of professional classical bassists, professional jazz bassists, students, and children.
We did receive some common feedback and quickly incorporated features that felt like no-brainers, At the same time, since this project was initially conceived with few constraints, we received very different feedback from different groups, prompting the question of “who are we making this product for?”
With each iteration, we crafted a more targeted set of features to test among the same relatively diverse groups of people. Since this product was never truly intended to go to market, we decided to create several “modes” — stratified software catering to a several specific user personas. For example, we added an “easy mode” where notes can only be perfectly in tune while another mode had a way for jazz musicians to achieve a realistic “pluck” sound.
Conclusion
This project taught me a tremendous number of new skills in hardware and software development. I refined my skills in prototyping through machining, laser cutting, and 3D printing while also learning best practices of coding in teams and the intricacies of timing algorithms. I learned how to use rather user-unfriendly industry standard PCB design software and foreign concepts in mathematics, igniting my curiosity for what other interesting and unexpected work goes into seemingly vanilla product designs.
Above all, my greatest takeaway was about the process itself — as they say, hardware really is hard. Iterations are time consuming and supply chain issues can happen without warning, so each iteration really needs to target a clear product vision through targeted research and experiments.
