If you purchased a plug-in only to find that it won't work with your host program of choice ’Äî even though the two support the same ’Äústandard’Äù plug-in architecture ’Äî welcome to the very large club. One would think, for instance, that if a plug-in is in VST 2 format, it would work fine with all hosts that support VST 2, and that AU plug-ins would work with all Mac hosts that support AU.

Unfortunately, things aren't that simple. In practice, some plug-ins work with one host but not with another that supports the very same format. Incompatibility is obviously a drag for end users, and it can be an expensive problem if you have purchased a pricey plug-in bundle or a hardware processor that relies on a plug-in front end (for example, Lexicon MX series, SSL Duende, and Focusrite Liquid Mix).

One's expectations of compatibility are even higher with proprietary formats such as Digidesign TDM and RTAS, which have to work with only one host ’Äî in Digidesign's case, Pro Tools. The same is true of using plug-ins for MOTU's proprietary MAS architecture, which is exclusive to Digital Performer. Both Digi and MOTU prequalify their development partners, so the host developers (both of which also make plug-ins) need only provide support and test plug-ins (both have extensive testing programs) for a well-defined group of plug-in companies. That makes it easier for them to inform their third-party developers about updates and changes that could affect plug-in performance, but it's still a huge job. After all, there are about 900 plug-ins for Digidesign Pro Tools alone. Even so, neither company can guarantee compatibility in all cases. Digital Performer supports AU as well as MAS, so MOTU still has to deal with the uncontrolled world of AU development.

Indeed, the worlds of VST and AU more resemble the Wild West. Although VST is developed by Steinberg and AU by Apple, these formats are not exclusive to their developers' host programs, and there are no restrictions on plug-in developers. Commercial developers have a financial interest in ensuring compatibility to the extent that their resources permit, but those resources may be limited. Some amateur developers are vigilant about compatibility testing, but others aren't. A validation program for Audio Units provides a variety of standard tests, which is helpful in ensuring compatibility. But nothing says you must use it. As with other formats, most host developers try to help plug-in developers ensure compatibility, but there are countless VST and AU plug-ins, so much of the testing falls, as it should, on the plug-in developers. The biggest compatibility problems by far are with VST, which also is slightly different on Windows than on the Mac.

Yet despite the host and plug-in developers' major investment in support, testing, and cooperative development, we still have compatibility headaches. Why?

For starters, gray areas in specification and documentation gaps can lead to problematic implementation. For instance, some specs define how a plug-in should work but leave out details about hosting. And sometimes, as Strother Martin famously stated in the movie Cool Hand Luke, ’ÄúWhat we've got here is a failure to communicate.’Äù Steinberg recently released Cubase 4, which uses the new and promising VST 3 architecture. But as of this writing, the VST 3 specification has not yet been released to third-party developers, so plug-in compatibility could be a problem for a while.

Creativity is a double-edged sword in the plug-in world. It leads to innovative products but can cause compatibility problems, even when everyone honors the specification. For example, if a plug-in has its own transport controls or clocking system, it may need the host to handle timing and tempo information in a certain way, and some hosts might not accommodate that. Hence, the plug-in may load and pass audio yet fail to operate properly. Host developers also add innovative features, and if a plug-in is written to take advantage of such a feature in one host, it might not work in other hosts. Normally, these problems are worked out cooperatively by the developers, but some solutions involve code changes that can cause bigger problems, so a fix may be impossible or too expensive to justify. The result can be incompatibility.

The Mac, in particular, has undergone an assortment of platform and OS changes, some of which throw a monkey wrench into the works. The shift to Intel Macs broke a lot of things, not just because the software had to be compiled for a different processor but because, for example, the way that AU plug-ins interact with hosts changed, which affected some plug-ins more than others. The move to Windows Vista will probably require adjustments, as well. Furthermore, some copy-protection schemes interact with the plug-in and the host, as well as with the operating system; changes in one can cause compatibility problems in the others. Developers try hard to adjust quickly, but most are small companies with limited resources.

Making things more complicated, some users rely on a wrapper to run plug-ins in apps that don't normally support the format. If you use the FXpansion VST Wrapper with Pro Tools, for instance, it should work with many plug-ins; there are no guarantees, though. Less obvious is the fact that some plug-in developers rely on a wrapper to create AU plug ins from VSTs. That usually works, but it's imperfect and can lead to compatibility problems.

And of course, we will always have human error. Whether there are errors in the spec or in the implementation of the spec or bugs in the code, compatibility problems can result, extensive beta testing notwithstanding.

Most of the developers I discussed these issues with agreed that we all would be a whole lot better served if we had one universal plug-in architecture that is cross-platform, written in an industry-standard language (like C++), robust and full-featured, and well documented with respect to both plug-ins and hosts. I suspect this could happen only if the standard were regulated by an independent organization, somewhat like the Audio Engineering Society and MIDI Manufacturers Association. That wouldn't eliminate all problems, but it would be a big step in the right direction.

Of course, it would not be easy to get companies like Steinberg, Digidesign, and Apple to buy into this, because they have vested interests in their own architectures. But I suspect many plug-in developers would support such a move, as would almost all electronic musicians.