The MIDIdial homepage: mididial.bartnett.com
The weekend of October 2nd last year me and my friend Dalia Coss rolled up to the HackNY 2011 Fall Hackathon, and won. Our hack was a webserver that would interact with Twilio and allow you to transform your phone into a MIDI controller via a touch tone menu. It doesn’t even have to be a cell phone. We’d like to thank Andrew Montalenti for showing us the Tornado framework for Python and Rob Spectre for letting us bug him all night with questions about the Twilio API. Also, shout out to Hacker League for making an awesome hackathon platform and testing it in the field for the first time there.
It was called midiPhon originally but some people with an existing iPhone app named midiPhon sent us a nastygram, so we’ve since renamed it to MIDIdial. We got some fun press for it, people tweeted how thought they cool it was, and we were mentioned in a couple of articles. Read on for info about how we did it.
From MIDIdial’s homepage you can see David playing with MIDIdial on his old school telephone. You can also find the Github page (click on the big DOWNLOAD SOURCE CODE link) and see our unadulterated cowboy coding. The program is split into two modules, the web server and the midi router. There’s some other crud in the repo because we played with supporting multiple sessions anywhere anytime hosted on AWS, but sort of decided we enjoy the setup process currently involved, and also wanted to move on and finish other things we were working on (more games!).
When mididial_webserv gets an incoming POST request from Twilio it goes to the resource handler associated with either a new number or an existing number dialing a new digit. The mididial_midi module hosts the MidiManager class which wraps up calls to PyRtMidi and handles assigning each new phone number its own MIDI channel. So mididial_webserv generates the appropriate Twilio responses (basically just telling it to endlessly loop asking for new keys) and calls methods on a MidiManager object to trigger midi notes and add new players.
So that’s MIDIdial. I’m not certain of the value of this other than as a fun project. Maybe some sort of DJ audience participation tool? If you have any ideas, email/tweet at me!
We spent a lot of time recompiling MIDI libraries for Python at the hackathon. A lot of them unfortunately seemed to be geared for working on Unix. We found multiple wrappers for port_midi, but were constantly running into either dependency or x86 vs x64 issues. Finally we found RtMidi, and while it’s kind of a strange interface for a library (unnecessary object orientation), it’s easy to use, supports opening virtual midi ports on OS X, and the python wrapper worked! So, at midnight on Saturday (roughly, might be totally pulling that out of my ass since that whole night was a blur), we finally got our first note routed.
Because the brunt of the work was in getting the MIDI wrappers working, we decided to make the architecture as simple as possible (clearly), and didn’t bother even deploying it onto a server with a database and everything. We used Localtunnel to run MIDIdial from our laptop during the demo. Information about participants in the jam sesh are stored in-memory. The only data generated is that it makes an attempt to record the midi performance, uploads it to our server, and texts everyone a bit.ly link to that server.
So that’s MIDIdial. I’m not certain about how it could be useful beyond being a fun thing to play with. Maybe an audience participation tool for DJs? If you have any ideas, let me know!