Illustration: DAVE EMBER
Last month I talked about some recent additions to the MIDI Specification that will help to keep it alive and relevant in the 21st century, and about the problems of running MIDI over USB, the ubiquitous connection scheme that's been replacing serial, parallel and SCSI cables over the last couple of years. If you missed that column, then you an check it out here.
This month, I'll look at how MIDI relates to IEEE-1394, the new communications protocol that's worming its way not only into the computer world, but also into everything from video cameras to dishwashers to cars.
IEEE-1394, as everybody knows by now, was developed by Apple back in 1995 and dubbed FireWire. It was adopted by the Standards Association of the Institute of Electrical and Electronics Engineers, and thus entered the public sphere with a boring name. (Apple will license its name and logo to anyone for free, but Sony calls it "iLink," and other companies use their own monikers.)
1394 is a serial protocol that runs at speeds from 100 to 400 megabits/second, and work is currently under way (and expected to be completed in the first half of 2001) to increase the top speed to as high as 3.2 Gigabits/sec. Even better, it can support multiple data streams simultaneously, bidirectionally and running at different clock rates--so you can be sending and receiving MP3 audio, 96kHz audio, compressed and uncompressed video, and MIDI, and at the same time scanning stuff into PhotoShop, all over the same 1394 cable, without any of them getting into each other's way.
Unlike MIDI, 1394 is not free for any manufacturer to use, but the licensing terms are pretty painless: There's no association to join or dues to pay, and no requirement that Apple or anyone else must certify that a 1394 device works the way it's supposed to. There is a charge of 25 cents per device that reaches the marketplace. (But for a handful of large companies, like Sony, Toshiba, Canon and Panasonic, that have joined Apple's patent pool, that charge is waived.) Originally, Apple wanted to charge much more, but in the face of competition from Intel's USB 2.0, according to some sources in the industry, they backed down. It was a good political move, to say the least.
Unlike USB, which was really created to replace mouse and modem ports, 1394 was designed from the ground up for media applications. Already, as we saw last month, USB is being pushed to its limits, and even consumers are catching on: As one source told me, USB-powered speakers are "failing miserably" in the marketplace. Even in the simplest of environments, USB systems can easily get overloaded--I spent a couple of hours with a client last month beating my head against a wall trying to figure out how to get her new iMac-based MIDI system working, until I realized that the fancy USB hub she had couldn't supply enough power to run her scanner, her fax modem and her MIDI interface at the same time!
Also, unlike USB, MIDI events sent over a 1394 cable have a guaranteed time of arrival, so the stopgap measures to make up for USB's problems and prevent MIDI timing slop and jitter, like Mark of the Unicorn's "MIDI Time Stamping" and other proprietary schemes, are not necessary. According to Jim Wright of IBM, chairman of the working group of the MIDI Manufacturers Association that's dealing with advanced data transport, MIDI and audio data over 1394 are tightly coupled when it comes to timing so that you can get perfect synchronization between them, at least with a reasonable number of audio streams.
Trying to get manufacturers to understand this has not been easy. According to one company, "We're hitting a brickwall with the multimedia giants. They don't understand anything less than a millisecond--or even a frame." I just finished working on a DV/FireWire-based film in which getting the audio and video to stay in sync has been a constant struggle. But, hopefully, this problem won't last as more developers get involved.
One of 1394's chief advantages to audio users is that devices using the protocol are "hot-swappable"; unlike with SCSI (but like USB), you can plug and unplug devices without turning anything off--although personally, I've been hot-swapping SCSI cables for years and never had a single equipment failure. (But I live dangerously.) So when you need to find that old file on a Zip disk but you forgot to connect the drive, or you want to add a new FireWire-based signal processor to your rig, you don't have to shut the whole system down. (I have encountered one area, however, where hot-swapping 1394 equipment didn't work: In the project I just finished, using a popular PC-based editing system, we discovered that an external video deck won't be recognized unless it's plugged in at the time you power up the system. Well, nobody's perfect.)
1394 cables are inexpensive, in that they consist of little more than a couple of twisted copper pairs, and yet the amount of data that can go down them is staggering. It may be a while before we find out what FireWire's limits are in terms of simultaneous audio and MIDI streams. But implementing it in hardware is not quite so cheap: You can find FireWire PCI cards for under $100, but one manufacturer says that putting 1394 into a typical audio processor, mixer or synthesizer would raise the cost by about $100, compared to a MIDI or even a USB port.
"It's not even on most motherboard makers' radar," according to one synthesizer manufacturer. But Apple (of course) already has it on its desktop models and some iMacs, and Sony has put it on its Vaio model PCs so that users can hook up their (presumably Sony) video cameras directly into the computer. And, as we've seen many times, once a new technological fad takes off--and 1394 is doing just that, as it will soon be showing up in everything from home appliances and security systems to factory automation to automobile "entertainment systems" (what, dodging SUVs and talking on your cell phone isn't entertaining enough?)--everyone wants in on it, and the price nosedives.
The MIDI Manufacturers Association has adopted a "MIDI-over-1394" specification, which, in turn, has been ratified by the 1394 Trade Association, so there shouldn't be any confusion about how MIDI is going to travel over a 1394 cable or how it will get along with its cablemates. (The MMA's early participation in the 1394 development process is one major reason why MIDI performance over 1394 is not going to be the problem that it is over USB.) The MMA's spec has also been incorporated into mLAN, Yamaha's nonproprietary extension to the 1394 protocol, which deals specifically with audio issues and is the first serious attempt to get an audio "layer" onto the FireWire spec. mLAN is now, or will soon be, available on a number of Yamaha and Korg products, and it will be interesting to see how the MIDI implementation of these products works.
There's no reason why a 1394 cable can't carry thousands of MIDI channels, with or without audio. And this opens up a door to something that not long ago we dared not speak its name: a MIDI 2.0 specification. The original MIDI spec allowed only a very limited number of channels on a cable, mandated a data rate that by today's standards is ridiculously slow and only permitted data to flow in one direction. Although it has expanded radically over the years, it has always had to work within those limitations. If the spec could be rewritten with 1394 in mind, then the potential improvements are staggering.
Of course, you could have 1,000 or 5,000 MIDI channels, but you could also have 1,000 controllers per channel and new types of controllers that are much more data-intensive than the current 7-bit ones, like, for example, 1 million levels of pitch bend, covering 10 octaves. The old MIDI spec allows for 14-bit controllers, but no one uses them because of fear, ignorance or simply economy. When bandwidth limitations go away, these could become commonplace. The speed of the MIDI line could also be increased by a factor of 10 or 1,000 or even made variable to suit different needs. And, instead of a dozen cables emerging from a multiport interface to power a dozen individual devices, there wouldn't even be a need for a specific "MIDI interface" anymore. A production system would simply consist of a daisy-chain of hot-swappable MIDI (as well as audio and video) devices that connect directly to the master computer or directly to each other without a computer in the middle. (Try that with USB!)
And, under a new high-speed spec, a MIDI system could for the first time be truly bidirectional. Musical devices could query and communicate with each other and with the host computer automatically--no more dealing with OMS or MediaPlayer setup files, because the system would reconfigure itself (and reconfigure your software, too) automatically every time you added or took away a piece of gear. In Jim Wright's words, "MIDI 2 would mean never having to read Sysex again."
MIDI 2.0 would, of necessity, be backward-compatible with MIDI 1.0--meaning, older devices would be accommodated, both physically and in terms of the data stream--and converters and breakout boxes with 1394 inputs and MIDI ins and outs would be hot-ticket items for some time to come. And the recent (well, almost two years old now) addition to the MIDI spec that allows multiple devices to be addressed in a Standard MIDI File would become the rule, rather than the exception. With hundreds of devices attached to a front end, the idea of limiting file exchanges between platforms that are limited to 16 channels will seem positively quaint, if not downright dumb.
Wright says he would be in favor of a MIDI 2.0 spec that represents a "broadbased effort, one which will involve manufacturers, musicians, academics and other key stakeholders." He favors an "'open-spec effort, similar to Linux's open-source." It's a fine idea, worthy of a community that started out by an unprecedented show of cooperation among competitors and has continued to grow in that spirit.
Before I close this discussion on the future of MIDI, I have to mention a sour note. It's relatively old news, but it's something that has made a lot of people in the MIDI world, including me, very angry and continues to do so. While the development of MIDI demonstrated how cooperation between companies, and the executives, engineers and marketers within those companies, could create a multibillion-dollar industry, this item demonstrates the opposite: What happens when a company that doesn't give a rodent's patootie about a significant aspect of the music-production community--its developers or its customers--gets its corporate fingers into it?
One year after Gibson president Henry Juszkiewicz publicly apologized for "the lack of information on the current situation at Opcode and the current short fall [sic] in tech support," and stated, "It is our sincere intention to improve this situation as soon as we are able," absolutely nothing has happened. Pleadings, petitions and, reportedly, offers of all kinds notwithstanding, Opcode Systems, which had the first working MIDI sequencing program on the Macintosh, introduced the first and still the most-used multiple-device driver software for the Mac, created the first MIDI-plus-audio sequencer on the Mac and whose software had fervent adherents at all levels of the industry all over the world--and taken over by Gibson in 1998--is dead.
There is still a Web site where you can download 18-month-old versions of Vision and Studio Vision (www.opcode.com, but not just "opcode.com," which takes you to Gibson's front page), and Gibson will be happy to take your Mastercard number, but it's not at all a sure bet that the software you get will work for more than 30 days. That's when you will need to enter a "response" to the company's copy-protection "challenge," because no one seems to be home at "Opcode" to send the responses. The single individual doing tech support for the products has had his or her e-mail account shut off.
OMS, its device driver software, despite a huge movement that has included thousands of individuals and hundreds of companies, like Digidesign, Emagic and even NBC, to get Gibson to place it in the public domain, remains in limbo. According to one former employee, "They could regain an enormous amount of goodwill by releasing the source code in such a way that it can be maintained. It could be open-sourced, given to Apple or the MMA, or to a developer willing to make a commitment to keep it an open standard that benefits all of the platforms' developers and users." It was a no-lose situation for Opcode. It would have cost Juszkiewicz nothing--OMS hadn't been generating revenue for years--and it would have made him a hero (well, at least he'd no longer be Cruella DeVille) among the computer music community. But it ain't happened yet, and time is running out.
If the company felt that it really needed to somehow get its investment back, then a year ago there were plenty of people willing to buy pieces of Opcode's other technology. But the longer Gibson waits (and the real story behind the legal wranglings in this case is even uglier than the Florida ballot counting debacle), the less that technology is worth. By now I'd bet that most of it would barely be worth putting on Ebay. (Although the Audio-to-MIDI and vice versa feature is still pretty damn cool.)
I've been using Vision and its variants for almost 10 years, and I plan to keep using it, tech support or no tech support, until either I am forced to go to a system that simply won't run it (I'm told it behaves itself under OS 9, but under OS X, all bets are off) or I need new features that other programs offer that will never find their way into this moribund program. It will be the third MIDI-sequencing program I will have had shot out from under me, because, once again, stupid business decisions have forced a perfectly good musical tool to disappear from the face of the Earth.
Opcode was just the latest in a series of synthesis and computer technologies that Gibson has destroyed--Oberheim and Zeta Systems being the two best-known. Why they do this is anybody's guess; perhaps they think that somehow it will help guitar sales. If so, then maybe they should have a little chat with Yamaha--one of the most successful guitar makers in the world--about being able to have it both ways. Whatever the reason, shame on Gibson. It makes me even more eager to find some other manufacturer who has figured out how to make a really good clone of an ES-335.