We explore the idea of understanding technology in terms of layers and abstractions, and how this makes it possible for a protocol like MIDI to be communicated via USB, Firewire and even Bluetooth.
It's not easy keeping pace with technology these days — you only have to blink and it feels like you've been beamed into a parallel, but more advanced universe. I'm sure we can all sympathise with the experience of being a non-technical person in a complex world; for example, while I'm pretty knowledgeable in my own field, try explaining how an engine works to me and you might as well be talking to a cheese and tomato omelette.
So given the complexity of modern technology, how is it that even the most non-technical people have no problem in using modern machines with the same ease as they would a knife and fork? The answer is that our understanding of technology is broken down into a series of layers and abstractions. Each layer is a self-sufficient unit of understanding, and we can understand one layer without having to know how the others work.
Software Synths: The Ultimate Abstraction
Perhaps the best examples of layers of abstraction are software synthesizers and effects. The concept of an on-screen Minimoog, when you think about it, is so way-out that very few of us have the faintest idea of what's really going on under the hood. When you twiddle the knobs with your mouse, what you're actually doing is passing new parameters to some very low-level program code. The gap between what appears to be happening and what's actually happening is enormous — and yet, the end result is the sound of a Minimoog.
Maintaining separate layers is a task that in itself requires processing power, and the best illustration of this is a 'portable' programming language like Java. The Java Virtual Machine (JVM) is a layer of software that sits between the processor and the Java program, and provides a standard platform with which to run a Java program so that programs written in Java can be made to run on any device with a JVM. While Java's been around for a long time now, it's not been used much in real-time media applications because of the processing power needed to support a virtual machine — but this may all be about to change.
Processing power will soon be so abundant that audio and video applications could be supported under a virtual machine — we're starting to see mobile phones supporting Java video games, for example, which are themselves pretty processor-intensive. The advantages of Java-type portability in media applications are tremendous. For a start, your applications would run on a much wider variety of processors, which could, in turn, lead to more diversity in the type of devices that we can use in the studio. Imagine running a control panel for a VST plug-in on a Bluetooth-equipped PDA connected to the main studio computer, for example.
But perhaps the biggest application for Java-based media processing would be for decoding audio and video. Java-based codecs would mean that any kind of file (or stream) could be played back or created on any type of device. What's more, the media files could contain embedded metadata about processing to be used on playback, and even the actual plug-ins to do the processing. Imagine having your hi-fi system doing the final mix on a recording, but optimised for your own living room!
Opposites Abstract
MIDI is basically an abstraction: if non-technical people knew how MIDI operated, they'd be surprised that it worked in the first place. After all, the idea that you can play a complex chord on a keyboard, send the notes sequentially and hear a chord at the other end sounds a little implausible. Of course, the reason it works is because the notes are sent very quickly, and most of the time this works very well; it's only when you play 16-note clusters as repeated 32nd notes that it starts to fall apart and the limitations of the abstraction become apparent. Television, by the way, is another example of this kind of abstraction: what looks like a moving picture is actually the result of a single flying spot of light that moves so fast that we perceive it as an area of light rather than a single point.
The abstractions are perhaps obvious with MIDI because it's easy to understand how, at the highest level, the MIDI protocol is used to send events for notes from one device to another, without requiring any knowledge of how, at the lowest level, the actual interface itself sends voltages down the cables to transfer the MIDI data itself. And this is where breaking technology down into layers becomes interesting, because if you separate the upper layer that contains the MIDI protocol from the lower layer that defines how data is sent from one interface to another, there's nothing to prevent you from putting the MIDI protocol layer on top of any hardware transport layer you like. Suddenly, the fact we used to use five-pin DIN cables to send and receive MIDI data becomes irrelevant.
MIDI information is now routinely sent via USB, for example, and this works pretty well, except when other devices on the USB port swamp the connection. Putting an existing protocol at the mercy of another 'carrier' protocol is a bit like asking someone to deliver a precious parcel for you as a favour. If it's someone you trust, who you know will take care of the cargo, then you can probably relax; but if it's someone you've never met before, who might stop off and do other, more lucrative, work on the way, you shouldn't be surprised if the parcel arrives late.
Bluetooth & MIDI
M-Audio's prototype Bluetooth MIDI interfaces, shown at the Summer NAMM show in 2001.So if you can use almost any interface you like to communicate MIDI data, how about sending and receiving MIDI over Bluetooth? Sounds like a great idea, and M-Audio even produced a prototype Bluetooth to Midi converter. However, I'm not sure if I'd like to do a live gig based on this technology, any more than I'd like my steering wheel to be connected to the wheels of my car using Bluetooth right now. But this idea illustrates two important points about abstraction. Firstly, you don't notice the nuts and bolts of the technology if it works: using MIDI over Bluetooth would be just like using MIDI via any other interface. Secondly, abstractions are fine until you realise they aren't perfect. The biggest problem with MIDI over Bluetooth is likely to be that Bluetooth communication links are much less robust than anything that is based on a physical cable. If you were on stage at a venue that was anywhere near a kitchen with a microwave oven, I wouldn't give much for your chances!
Bluetooth is actually a very good example of a particular type of abstraction called a protocol stack, which is actually much easier to understand than it sounds, although experts would probably think the following is an oversimplification. Essentially, a protocol stack is a way of connecting two concepts or phenomena that might appear to have very little to do with each other: in this case, radio waves and abstract data. At the radio end of the system, Bluetooth uses a frequency hopping technique that bounces between 79 frequencies at 1MHz intervals at up to 1600 hops per second. Other layers include the 'discovery' protocol, where Bluetooth devices search to find other, compatible equipment, and the 'profile' layer where the nature of communicating devices is matched to a known set of characteristics, such as those of a headset, a modem, or indeed MIDI. Each layer in the stack is completely unaware of the lower levels — unaware, but not necessarily unaffected, since a problem at any of the lower layers can have unpredictable effects on any of the higher ones.
While all this talk about layers and abstraction can seem complicated, at least you can take comfort in the fact that most of the time we rarely perceive the abstractions at all. Playing a MIDI keyboard that's connected to a computer via a MIDI interface produces the same result as a MIDI keyboard connected via USB, for example. So the fact abstractions are rarely perceived is actually the whole point of this approach in the first place.