Avoid the M-Audio Mid Air

When I designed my springbok controller (for those of you new to my work, that’s a controller made from springbok horns not a controller of springbok) I planned to make it wireless. Why be tethered to a computer when you could be free to run around, stage dive, or order drinks while performing? It looked like the technology was available to support DIY wireless: Sparkfun offers Bluetooth modules that allow for the transmission of serial data, which is what the Arduino transmits, and there is plenty of software that allows for serial communication between applications and a laptop’s Bluetooth module (the rxtx Java API, the MAX serial object, etc.). I did get the controller to communicate with my application via Bluetooth with rxtx and the MAX serial object, but ultimately neither worked for musical performance because of unacceptable latency. Testing showed worst case latencies of up to 50 ms, which is an eternity in musical performance. Improvising with this controller was like pushing a shopping cart with a sticky wheel. I later learned that this latency is built into the Bluetooth SPP protocol, and that to get the lower latency achieved by the Wiimote, I would need to use the HID protocol, which in turn would require a different Bluetooth chip. It also means I wasted > $120 on two Bluesmirf modules. Hooray for learning!

So I turned to a commercial solution: the M-Audio Mid Air, which theoretically pipes MIDI data through the ether. I built a MIDI Out port into the controller and planned to send MIDI data from it to my Traveler interface. The first Mid Air that I tried burned out seconds after I turned it on–literally. I smelled melting electronics. The online retailer where I purchased the product, The Midi Store, was helpful in replacing it, but unfortunately the replacement, while it hasn’t burned out, simply doesn’t work. The transmitter and the base unit don’t connect. The device is MIDI’s answer to Samuel Beckett. Avoid it.