September 1995

Fear of Frying (my studio)

Let's Stop Progress Before it Stops Us

by Paul D. Lehrman

I get a distinct sense of dread these days whenever I fire up my home studio. I get the same sense of dread when I answer the phone and one of my students is on the line. Something horrible has gone wrong, or is about to go wrong -- something that will take hours, if not days, to track down and fix, that will have me arguing with a round robin of customer support people, that will cause me to miss a deadline or my students to blow a large part of the semester.

This dread doesn't come from any change in my medications or the makeup of the current US Congress. It's a result of the fact that the past 12 months have been a banner year for technical disasters of all kinds. My entire studio was down for six weeks, and cost several thousand dollars to get running again. In the college courses I teach, students who are supposed to be mastering sequencers, synthesizers, patch editors, samplers, synchronizers, and hard-disk systems, this year learned primarily about bugs, crashes, incompatibilities, trashed files, and how much hair their instructor can pull out in one session.

Oh, I'll be the first to argue that serious students of the recording arts need to learn this stuff: technical failure is part of the real world, and being prepared to deal with it will make them highly valuable to future employers. But this year the balance between the amount of time spent creating music and the time spent recovering from disasters shifted radically, so by the end of the semester, it felt like very little real work had been done.

Talk to many people in the industry, and you'll get the same story: down time in their studios has increased while those intervals in which they can actually do anything are getting briefer and further apart. It's ironic: years ago many of us who struggled with primitive software and hardware were telling anyone who would listen that computers would someday save all of us time and money, and allow us to realize all of our audio dreams. Now that everyone has bought into that idea, and the entire music industry is totally dependent on our computers to accomplish even the slightest task, those very computers are in danger of making it impossible to produce anything at all.

How did this happen? I see three general principles at work, which have recently achieved a kind of convergence: the "infinite upgrade spiral"; the "we can't test everything" syndrome; and the "we've got to do it first" mantra. For the people who design and sell the tools we use, these principles may represent lots of fun and profits, but to those of us who have to use them, they are poison.

Here's how the first one works: You buy an upgrade for a piece of software, let's say a digital audio editor. You install it on your computer, only to find that in order to get it to run, you need a newer version of the computer's operating system. After you install that, you find that all of the customizations you've done to your computer over the past five years -- the fax mailer, the network sharer, the E-mail gatherer, the custom keys, the automatic backup -- are no longer usable. You have to get new versions of all of them, and re-install and reconfigure them one at a time.

But the new editor, combined with the new custom stuff and the new operating system use more memory than the old versions, and so you've got to double your RAM. You shell out for the memory (which costs an order of magnitude more than the software upgrade), but then you discover your computer doesn't see all of it, because when its ROM operating system was designed, it had a RAM ceiling on it. Five years ago that ceiling was plenty high, but today it's pathetic. Looking through the back pages of a hacker magazine, you find a small company in East Overshoe that will trade your computer logic board for a used logic board from the next generation of computer. This will cost you only slightly more than what you just paid for the extra memory.

When the new board arrives, it has one less peripheral card slot than your old board, and suddenly you have to choose between running that nice large video monitor or using your digital audio system. But the choice has actually been made for you, because your old audio hardware, for which you just upgraded the software, doesn't work on the new computer, because in between models the computer manufacturer subtly altered the clock rate of the peripheral bus just enough to make the audio card non-functional. For a reasonable fee -- equivalent to the sum total of what you've paid so far -- you can upgrade your audio hardware. Now, of course, you'll need new software...

Believe it or not, with very little exaggeration, this is what I went through this year with my home studio. I now seem to have it all stabilized, but just barely. I can't use the latest digital audio hardware, I have to turn off all of my customizations if I want to run digital audio with my sequencer, and my computer is a bizarre hybrid that no service center will ever touch. I am now three versions behind the latest operating system, but whenever a fleeting thought of upgrading enters my mind, I pour a large drink and head straight for bed.

As for the second principle, a trial that my students underwent is a fine example of that: In class one day, a student attempted to play me his current project, which used MIDI and hard-disk audio synced to SMPTE-striped videotape. Whenever he started the tape anywhere besides the very beginning, the MIDI data wouldn't play smoothly, but instead erupt in dense spurts, about a second apart. We eliminated sequencer tracks one by one, and eventually got the sequence to behave itself. We then rebuilt the sequence, using the parts we had cut, and everything seemed to be okay.

The next day, a different student called. He was having the same problem. Over the weekend two more called, and by the next week's meeting, the entire class's work had come to a standstill. We optimized the hard disk containing the audio files. We searched for viruses. We replaced the hard disk. We re-installed the sequencer. We re-installed the system, and took everything out of the operating system we could. We called the sequencer manufacturer: obviously it was the fault of the accelerator card we had installed, which had been running fine for four years. We disconnected the accelerator: no change. We tried other SMPTE sources. We called the maker of the SMPTE-to-MIDI convertor: obviously it was a problem with the sequencer software. And round and round and round. For two more weeks, the students got no work done.

Finally, I removed the SMPTE-to-MIDI convertor (a model with "2" in its name) from the studio and replaced it with an earlier model from the same maker. The problem disappeared, and it has not come back. As I gaze at the river slowly running past the window of my office, I feel a warm glow knowing that the convertor with "2" in its name is now resting on its bottom.

The third principle can also be described as "creeping featuritis". In any rapidly-developing technology where several developers compete this is a problem but it's gotten ridiculous. I'll illustrate with one case I am particularly close to: Macintosh sequencer manufacturers are falling all over themselves to make their products all things to all people, especially with regards to generating music notation and manipulating digital audio. The problem is that a lot of these features don't work very well, if at all. But following the dubious lead of Microsoft (whose innovative approach to marketing has gotten them a lot of attention from the Justice Department), manufacturers now announce new products and features "defensively": they don't actually exist, but since the competition is already touting that they've got them, everyone feels they have to play catch-up or risk losing customers. Unfortunately, this "strategic vaporware" strategy often causes a company to fall on its face: the announced feature turns out to be impossible to implement, or it's implemented so badly it's unusable, or it requires so much jury-rigging of the software code that the program never works properly again.

And of course, the more junk you add to a program, the more chances for something to break. So you end up with a program that doesn't quite work, and when whatever doesn't work now is fixed, something else won't quite work. The White Queen in Through the Looking Glass knew this routine: "The rule is, jam yesterday, jam tomorrow, but never jam today!"

Even if the onslaught of new features manages to avoid technical catastrophe, software designers, in their mad dash to include everything including the kitchen sink, lose sight of their original vision for the program. So instead of being an integrated set of tools for making music, the programs degenerate into a designed-by-committee catalog of unrelated functions, leaving the hapless user to scratch his head over whether any of these wonderful features can actually help him finish a project.

Although manufacturers will always claim that they are issuing new versions of their products in response to users' needs, in reality many times upgrades are mostly bug fixes, or consist of features that were promised for previous versions, but there wasn't time to finish them before the last release date. Sometimes there will be new features no one really asked for -- they are thrown in to make it seem as if this is an important new version, and to justify asking users to pay for it. Rarely, however, is any of this truly helpful to the user -- more often it's all he can do to keep the new version from pushing him backwards: it takes a while to feel as adept with the new software as he was with the last version, but he's got to get back to work, so he can pay for all of this. So except for those features he must know right away, he never has the chance to learn any of the cool new features.

Can we do anything about this? Can we slow down "progress" enough to make sense of it? Or have we reached that assymptotic point on our industry's development curve where it has become a vertical wall; where technological development has utterly overwhelmed our ability to deal with it? In the "real" worlds of finance, education, law, and communications this has become one of the most pressing questions of the decade, so why should our little corner of the world be immune to it? We are fortunate, however, that our industry is still relatively small, and well interconnected. Perhaps by recognizing the problem now, and working together to solve it, we can avoid the kind of crises so many others are facing.

One negative factor that we may not be able to do anything about is that we live in a world where our fate is largely dictated by the two computer giants: Microsoft and Apple. A decade ago, when models and operating systems evolved relatively slowly, it wasn't all that hard for developers to keep pace with the changes. In recent years, however, the rate of change has taken off exponentially, and no sooner is the development community compfortable with one platform than it's superceded by the next version. Apple in particular has been guilty of this: its obsolescence timeline was once three years, but it has now shrunk to six months, with each new model not only requiring a new operating system but even new hardware specifications -- as one disgusted Apple engineer puts it, "they keep breaking the serial ports." With their software dependent on their hardware, and their hardware dependent on the whims of the computer companies' marketing department (none of whom could give a fig about the music market), developers are not in a happy situation. But still there are ways we can help make this work. The first is for users and manufacturers to adopt an attitude that we really are all in this together. Recognizing standards, and sticking to them, is important. When the Compact Disc was introduced, many people knew that there were good reasons to use higher sampling rates and longer words than the format provided, but they were impractical at the time, and it was more important to get the medium established than to wring every last possible ounce of performance from it. If they had waited for the next generation of technology, the medium probably would not have caught on anywhere near as well as it did. MIDI, too, was slow and finicky, and had its detractors, but it has enhanced our ability to make quality recordings far more than even its strongest proponents imagined. The lesson here is that cooperation is crucial -- without it, hundreds of companies may develop killer technologies, but they'll be stranded on hundreds of desert islands screaming their lungs out about it, with no one to hear them. Standards like VITC, AES/EBU, OMF, ADAT, MMC, and Control-L not only allow but demand that our tools all work together. Competition is fine -- it spurs excellence and innovation -- but meaningless one-upsmanship and deliberate incompatibilities do no one any good.

Second is for manufacturers to take the task of supporting their users a hell of a lot more seriously than they do now. Customer support is still the bastard stepchild at many companies: it's treated as a necessary but distasteful task you have to do after the real fun of selling them the product is over. Even companies that have real support departments often have the wrong attitude: one executive (hired from outside the audio industry) actually confided in me he was looking for ways to make customer support a profit center. He's going to have a long search. Support is an inevitable, necesssary expense, and the earlier that's written into the business plan, the better off the company will be.

It's been said that we no longer buy computer tools, we subscribe to them -- and subscribers need to be serviced regularly and well. Users of music and audio technology are busy people, and we're creative, and most of us are not stupid. We want the kind of help that recognizes our intelligence, and we want it to be accurate and relevant, and we need it right away. Staffing hundreds of customer-service lines around the clock is beyond the resources of most companies, but new technologies should allow the resources they can afford to be used much more efficiently. Menu-driven automated switchboards (designed by non-sadists, please), fax-back services, 800 numbers, and prompt responses to voicemail are some of the ways companies can respond economically to users without raising their ire.

On-line services are still woefully underutilized. Competition has brought the price of communications hardware and Internet access down to the point where many manufacturers can afford to include, right in their products, a modem, access software, and either a free trial subscription to an on-line service or an account on a private BBS. Designing a FirstClass-style host or World Wide Web page with menu- or icon-driven access to frequently-asked questions, implementation ideas, diagnostic programs, and other information is now ridiculously easy. For solving really thorny problems, the information contained in an on-line discussion thread can be even more valuable than a live support person -- someone, somewhere has experienced the same dilemma you're currently embroiled in, and has solved it. But this information isn't going to magically appear on line by itself: someone has to compile it, put a really good search engine on it, and put it on a server with enough room to keep a couple of years' worth of discussions.

Finally, manufacturers need to let products mature. A functional, solid, bug-free program is worth far more than something that contains every bell and whistle in the universe but that falls over if you turn your head the wrong way. These are creative tools -- every time a manufacturer does a major rewrite, it is forcing the creative types using the tool to stop whatever it is they're doing and learn the tool all over again. Imagine how guitar players would react if every time Fender came out with a new model it had a different number of strings in a different order, and the frets were arranged in a new way.

Yes, manufacturers, please fix bugs. Yes, make things slicker and more efficient. But no, you don't have to throw in every feature that anyone has ever asked for. No one feature is going to make or break a product. Besdies, a lot of the time users are just wishing out loud, suggesting something for its coolness factor, not because they would ever use it. Don't fall for the "flavor of the month" mentality, and don't worry so much about customers jumping ship if you're missing this feature or that. Users in this industry are more loyal than that, if for no other reason than they can't afford the effort and downtime required to learn whole new programs. And while you're at it, please stop lying to your customers. Touting features that you know don't work, boasting about compatibilities that are still on the drawing board, and listing misleading or downright hallucinatory specifications won't win you any friends, or prevent customers from going to the competition. They will, however, tie up your support lines, where you're not making any money.

I don't want another year like the last one. I want to make music, and I want to teach my students how to make music and use all these wonderful tools we've developed. I love my studios, and they can do, right now, just about everything I want them to do. If I have to stop upgrading my studios completely so that they continue to do so, I can live with that. Perhaps eventually the dread will recede. Somehow, though, I doubt this will happen -- keeping up with the latest technology as it speeds by is too damn much fun. But always keep in mind that in music technology these days, as has long been true in life, it's important to remember that speed kills.

Paul D. Lehrman is a composer, writer, and teacher at the University of Massachusetts Lowell.

These materials copyright ©1995 by Paul D. Lehrman and Intertec Publishing