Just about any computer audio jock these days will tell you about the greatness of the plug-in. Plug-ins have been credited with solving numerous problems and delivering more to the hands of the electronic musician. Yes, look at any ad, read any review copy, and you're sure to think these software modules are the greatest thing since MIDI. The mantra is that plug-ins mean power, and if you're using Windows, that means Direct-X plug-ins. Really now? Are they all they're cracked up to be? Well, uh, sure, they must be good... after all, there's so many of them out there now... all the big companies are pushing them... they wouldn’t try to pooch us now, would they?

What exactly have folks been claiming as the advantages of Direct-X plug-ins? Over the past year or two, the following have appeared in various computer/electronic music magazines.

1. High quality processing (24 bit resolution).

2. Real-time operation.

3. Direct-X is really efficient.

4. It’s a standard, so everything works together.

5. Modularized design let’s users create custom software configurations.

6. You can chain together several effects.

First off, 24 bit processing has nothing to do with plug-ins, per se. Lots of applications can do 24 bit resolution editing (Sample Wrench 24/96, for example). Plug-ins bring nothing new to the table. Second, real-time operation has nothing to do with the plug-in scheme. Again, lots of programs could do real-time (for example, Sample Wrench has real-time preview of many effects). Third, the term Direct-X is somewhat misleading here. Direct-X plug-ins use what is currently known as Direct Show (and given that Microsoft has already changed the name several times, we can only guess what the name will be tomorrow). This is not to be confused with the Direct-X sound/graphics layer used by games (the stuff that’s more efficient than normal Windows, which of course, isn't saying a lot). In fact, the plug-in architecture is based on COM, which is not a very "light" technology. That’s why so many of these programs need to be run on fast machines for decent performance. It’s rather like using a hammer to kill flies. Hammers can indeed be used to kill flies, and the flies will definitely be dead if hit, however, your furniture may suddenly acquire the antique or distressed look. This leads us into item four, the standard mantra. Ask yourself the following question: Is ANY standard a good standard? Standards are good when they attack a well defined problem efficiently, and are open to all. Direct-X is proprietary Microsoft stuff. It is not open. It is not supported outside of Windows. As a third-party programmer, you take what Microsoft gives you, and that’s that. The end result of this top-down mentality is that there are almost always glitches and incompatibilities between the various implementations of the standard. Of course, the developers tend to blame the other guy, and code implementations are seen as proprietary, so everything continues to work just a little differently everywhere. Did you ever wonder why a review might say that brand X’s Direct-X system is better than brand Y’s? If the standard really was open and the software companies’ primary concern was the customer, shouldn’t this be a level playing field (ignoring the possibility of a really dim programmer or dumb bugs)? The fact of the matter is that Direct-X was not designed to be a really efficient architecture for modular audio software, but that hasn’t prevented some developers from recognizing that it could be contorted for that purpose.

Speaking of modularity, what about items four and five? Isn’t having the ability to create custom software configurations worth something? Maybe, sorta, kinda. Remember, if you’re working on a computer with a pre-emptive multi-tasking operating system, there’s nothing preventing you from running several audio applications simultaneously (assuming that the programmers didn’t do unfriendly things like hog the audio or MIDI devices). The modular advantage boils down to having one application appear inside another. (Depending on how the software is written, there might also be a file loading advantage.) Hey, on Windows you’ve got the Taskbar. Grab the other application. Was that hard? OK, OK, some people really like doing everything in one application. That’s fine too, just don’t forget the overhead. Ultimately, it’s a rather minor blip in the grand scheme of things. Really, all you get is a few new menu items. That’s a far cry from truly modular software, and it’s certainly not custom. There is an old saying among programmers: The only truly customizable software is that to which you have source code. That’s one reason why Sample Wrench offers the Enable scripting language; you can create your very own unique signal processing functions or create your own graphical interface for any of Wrench’s built-in functions. That’s custom.

Finally, as far as chaining effects is concerned, that is something that can’t be duplicated with simple multi-tasking. Then again, is this something that you really need for off-line editing? Many people would rather do their edits a layer at time, so to speak, making sure that each step is just right. After all, it will take just as long for the computer to perform the calculations whether it’s done step by step or chained.

In sum, it’s fair to say that a group of audio developers could get together and come up with an open plug-in scheme that is more efficient than Direct-X and that could be used cross-platform (the spec that is, code always needs to be compiled for the target microprocessor). With a little thought, it could probably do more than just insert a few new menu items into an application.

OK, so if the picture isn’t nearly so rosy as has been presented elsewhere, why are so many manufacturers pushing Direct-X audio plug-ins? Here’s the dissidents theory. Fear and money. Fear because no one likes to get in the way of a runaway train, especially if that train is owned by Microsoft. Money because, well, it’s money. Plug-ins are perhaps more accurately called profit enhancement vehicles. There are two sides to this coin, and both make money at the consumer’s expense (surprise!). First, take the company that only makes plug-ins. These folks get to create effects processors without worrying about the details of a user interface such as drawing a waveform. This saves them tons of time. All they have to do is work on the DSP code. Of course, since this plug-in is now advertised and seen as something special, they still get to charge a good penny for it. Not a bad situation for them. On the other side is the company that sells a host program, along with their own plug-ins. Now, suppose that you own such a company and it has good market penetration. How do you keep the dollars rolling in? Well, since expansion is pretty limited, you update the product and charge a good buck for the update. You can maintain a pretty good return by only offering the update directly, not through dealers, at perhaps one quarter of your "sticker price". For example, a $500 list program may be sold to a distributor at 40 to 50% ($200 to $250). If the update is priced at say $100 to $125, you’re still getting a good chunk since there’s no middleman. Of course, this little train ride gets irritating to the customers after they’ve done it a few times. What to do? Well, how about packaging a bunch of new effects not as an update, but as a separate product, a plug-in? The consumer will think it’s the latest and greatest, and you can even up the ticket to board the train! Not a bad deal for Mr. Developer. Maybe not the best deal for Mr. Consumer.