On April 20, 2014, I held my first public performance using an instrument I built and programmed.
It was a gamepad-controlled musical instrument, combining off-the-shelf hardware and open source software.
The performance was held for Sunday Assembly Atlanta (SAA), a secular organization whose motto is: Live Better, Help Often, Wonder More.
(For the folks at SAA – I apologize for taking so long to write this, but here it is – along with the source code on GitHub – for any geeks in the crowd who want to play with it themselves.)
After finishing a critical phase of a work-related project, I now have time to write an overview of what I did, why I did it, how it turned out, and what I learned.
Why do this?
I started thinking about this project after attending the first two meetings of Sunday Assembly Atlanta. There were several parts of the meeting where we did karaoke, and I was wondering whether there was another form of musical interaction – perhaps even unique to the organization – that we could do as a body. That got me thinking about new ways of looking at how music could be made and how it could be experienced.
Thus began this experiment in collaborative music.
What did I build?
Over the course of a few months I built a “shared” instrument that used wireless PlayStation3 controllers to build loops of user-selected samples. The audience would pass around the controllers to add and remove samples from musical tracks that had predefined beats and time signatures. The patterns they created would be be projected on a screen as a sequencer-like display.
[youtube=http://www.youtube.com/watch?v=el22V6u63Uw]
Why did I build it this way?
I know a lot of different programming languages, but really didn’t have a good idea of how to create sounds (much less music) starting from raw code. I needed to use something that met the following criteria:
- Didn’t take too long to learn
I wanted to start and finish within a reasonable period of time; - Cheap/free to learn
I’m thankful that in this day and age, you can learn pretty much any programming language for free (More on this later). - Had a community of users who could offer suggestions and sample code
No one wants to reinvent the wheel if they don’t have to;
I narrowed it down to two languages: ChucK and Processing. I had recently learned ChucK through an instructor-led Coursera class. Once done, I found the language easy enough to use to do the types of projects I’m thinking about.
Processing I learned almost at the last minute because it had a framework for receiving Open Sound Control (OSC) signals. The language wasn’t that hard to grasp since I’d used something like in when I was playing with Arduino micro-controllers.
So…how does it work?
I used five PS3 DualShock Sixaxis controllers as the physical part of the instrument. I chose these controllers because (1) my son had one that I could experiment with; and (2) other than a Bluetooth adapter and USB cable, they don’t require any additional hardware to connect to the computer.
The sound generators are a collection of scripts written in ChucK. Some scripts assign a collection of samples to each gamepad that’s linked to the computer. Other scripts define a common time signature and set of note lengths.
Again, the Processing sketch handles the visual display.
Each game pad controls a track. A track has collection of samples and a time signature assigned to it.
Once the sound generators start, they listen for the four buttons on the right side of the pad being pressed. Pressing those buttons assigns a sample to a beat that gets played during the next loop.
Code summary
Here’s the high-level summary of what each of the scripts in the instrument does.
initialize.ck
- calls the global classes
score.ck
- creates the tracks
- assighs sample groups to each track
- sets the asderss and port number the tracks send OSC signals on
BPM.ck
- global time signature
- sets beats per minute (that is, the tempo of the piece)
- sets durations for quarter, eighth, 16th, and 32nd notes
SoundChain.ck
- master volume
BaseTrack.ck
- Defines the properties and methods that all track types have in common .
Track.ck
- A type of BaseTrack
- Adds more properties and methods specific to what I want this instrument to do.
AutoTrack.ck
- Another type of BaseTrack – not implemented.
- It was meant to take information about what was played so far and use some rules to automatically generate sounds or kick off samples.
joystick_test.ck
- Joystick testing code borrowed from one of the examples on the ChucK site
rec-audio-stereo.ck
- Records audio from the tracks
TrackSequence.pde
- Processing sketch file for the instrument’s visual display.
- Listens for signals from the tracks and displays them as a sequencer-like display
How do you hook up the game controllers?
I’m running an Ubuntu Linux system, so my process for getting the PS3 controllers hooked up via Bluetooth will differ from other systems. Once you’ve got one set up, hooking up others easy – it’s the same process.
I hooked up five controllers for the Sunday Assembly event, and from what I’ve read in various places, you can hook up as many as seven. I didn’t have time (or money) to buy a bunch of PS3 controllers, so I asked for folks to let me borrow any they could spare.
One thing to be aware of is that if you leave the controllers idle for too long, the Bluetooth connection drops – so keep an eye on their usage.
How did it go?
Despite a slight hiccup – and what public demo doesn’t have one? – we got the setup working so that people could play with it after the meeting. People seemed to find it interesting, and I got a lot of questions about how I built it. I also got suggestions from the audience and from people outside of Sunday Assembly for new rules, new samples/instruments, and new interfaces.
Here’s the raw audio (converted to MP3 format):
[soundcloud url=”https://api.soundcloud.com/tracks/150582520″ params=”color=00cc11&auto_play=false&hide_related=false&show_artwork=true” width=”100%” height=”166″ iframe=”true” /]
It’s a long file – I kept it running while people were eating brunch after the meeting.
I really appreciate all the feedback I’ve gotten – it will definitely influence not only the next iteration of this project, but future projects as well.
Lessons learned
- When proposing a project that you’ve never done before, either keep your mouth shut until you have a proof-of-concept already done, or give yourself a *lot* of time to develop and test the project. Given what I do for a living, I should’ve known better, but I let the “holy crap, this is so cool!” aspect of it cloud my judgement of the level of effort involved.
- Nothing is more motivating than making an announcement in front of people, and then striving to meet their expectations.
- To make this work better in the future, I need to use a more ubiquitous device to act as a user interface. The most obvious would be smartphones, and I’m looking into how I could incorporate smartphones into future shared instruments.
Update: Source Code Is Available
I’ve uploaded the source code to GitHub for those who want to play with the code.
Have fun with it, and let me know if you get anything useful out of it.
Leave a Comment