Pluggin' In to Windows

Windows-based musicians may have more plug-in choices than they realize. Plug-in compatibility may not necessarily be a simple yes-or-no proposition. To provide more options for users of DirectX-only host software, several developers have created wrapper applications.

I have a dream. Someday I'd like to be able to install a new piece of music software on my Windows PC and know in advance that it will work with all of the plug-ins in my system — no hassles, no headaches, no hang-ups. Alas, that glorious day has not yet arrived, but some progress has been made. Recently, I set out to evaluate just how far we've come and how far we still have to go.

In the Windows world, plug-in effects and plug-in synths come mostly in Microsoft DirectX and Steinberg VST formats. To add a plug-in to a host application, the plug-in and the host must use the same format. Some host applications, such as Steinberg Cubase SL and SX, Steinberg WaveLab, and Image-Line Fruityloops, support DirectX and VST. Others, such as Cakewalk Sonar, speak only one dialect (DirectX in the case of Sonar).

All of the standard types of effects are available in both formats, so it's not as if users of a VST-only or DirectX-only host program are likely to be drastically shortchanged. Some plug-in manufacturers even provide VST and DirectX versions on the same disc, so you're covered no matter what host you're using. Nevertheless, some very good plug-ins are available only in one of the two formats. If you want one of those effects (and you don't have the proper host), you might have to do some fancy footwork.

Moreover, plug-in compatibility might not be a simple yes-or-no proposition. For example, a program that boasts DirectX compatibility might host DirectX effects but not support a DirectX Instrument (DXi). Similarly, a program such as an audio editor without MIDI capabilities might support VST effects but not a VST Instrument (VSTi).

In addition, programs handle the automation of plug-in parameters in various ways. Ideally, you should be able to arm the host program for automation recording, grab a knob or fader in the plug-in, and record your moves for later editing and playback. However, some programs that host DirectX effects won't let you automate them. Or you may be able to automate DirectX effects but not the controls of DirectX Instruments. And some effects are not automatable no matter what program is hosting them.


To provide more options for users of DirectX-only host software, several developers have created wrapper applications. These handy utilities “wrap” a VST plug-in so that the host thinks it's a DirectX plug-in. I looked at three popular wrappers: FXpansion's VST-DX Adapter 4.0 ($60;, Spin Audio's VST DX Wrapper Pro ($40;, and Kirill Katsnelson's DirectiXer ($49; Each performs its magic in a slightly different way.

With all three wrappers, once you've converted your plug-ins, you should never need to run the wrapper software again (until you acquire new plug-ins). The wrappers become invisible; the plug-ins appear in the menu of the DirectX host as though they were standard DX plug-ins (see Fig. 1).

DirectiXer operates in a window that shows a list of the plug-ins you've already converted (see Fig. 2). That's useful — you won't convert the same one twice, and you can delete items you no longer want cluttering up your menus. After using a standard file dialog box to select the DLL file corresponding to the plug-in, you can choose various options, such as Send Parameters As MIDI NRPN Messages and Force Stereo Processing. You can also enable or disable individual audio outputs for a multichannel synth plug-in. I like this program's flexibility, although I left the default settings pretty much the way they were most of the time.

VST-DX Adapter is a batch processor. You show it the disk directory paths where your VST plug-ins live, and it converts everything in the paths. If you have plug-ins that you don't want converted, you must remove them from the folder before running Adapter. For example, some of the VST plug-ins that come bundled with Cubase can't be converted, so when VST-DX Adapter finds them, it spits out a long series of error messages (see Fig. 3). After this first stage of the process is complete, you get a list of plug-ins in a window, and you can configure their properties (though there are fewer options than in DirectiXer).

VST DX Wrapper Pro looks rather like an installation wizard complete with Back and Next buttons (see Fig. 4). You select a VST plug-in from a list or by using the Browse button, name your converted plug-in, and the job is done. This program offers none of the options found in the other two for customizing the behavior of the plug-ins. Also, the ReadMe file suggests that VST DX Wrapper Pro is outdated — it refers to older host programs but not newer ones like Sonar. And it specifically mentions VST 1.0 but not 2.0.


Given the vast range of software available for Windows, I couldn't test every possible combination of host, wrapper, and plug-in. I therefore chose several programs to represent a cross section of typical music applications.

My main programs were Cubase VST/32 5.1, Sonar XL 2.0, Fruityloops 3.4, and Sonic Foundry Sound Forge 6.0. My plug-ins included various VST synths, such as Native Instruments FM7, VirSyn TERA, and Steinberg's Waldorf Attack and Waldorf PPG Wave 2.V. I also included Camel Audio's nifty little distortion effect SuperCamelPhat 2.0, Big Tick Audio's Hexaline (a freeware VST chorus unit), the Waves Gold Bundle DX effects (I started with version 3.0, which doesn't allow automation, and later upgraded to 3.5, which does), and other VST and DX effects that are installed along with the various host applications.


Cubase easily hosts both VST and DirectX effects. They all show up in the pop-up menu, and for the most part they work as expected. The only DX plug-in effects that didn't work in Cubase were the ones whose names begin with Cakewalk FX. Other Cakewalk plug-ins worked, but the FX set wouldn't instantiate.

That is not unusual in the world of bundled plug-ins. For example, as mentioned earlier, Cubase ships with a set of VST plug-ins that can't be used in any other program. One way to view the situation is to think of the host application as a sort of copy-protection dongle for the plug-in. Older Steinberg VST plug-ins, such as Fuzzbox and WunderVerb3, can be used in other programs. Indeed, they were converted by all three wrappers and then operated as expected in Sonar.

According to the manual, Cubase will automate the first 15 effects parameters in the first 32 audio channels in the mixer as well as in the 8 Group and 16 ReWire channels. When you instantiate a software-synthesizer plug-in in Cubase, it appears in its own stereo channel, but because it's neither an audio, Group, nor ReWire channel, the effects processing the synth can't be automated.

Cubase won't let you instantiate a DX Instrument in its VST Instruments panel. Fortunately, most of the hot software synthesizers are VST compatible, so Cubase users have little cause for complaint.


When I started testing plug-in automation in Sonar, I was balked briefly because the manual fails to explain that the program won't record automation data if any tracks are enabled for recording. Once I got that wrinkle ironed out, I found that many effects, including some wrapped VST effects, would automate just fine. The Waves Gold 3.0 bundle (DirectX effects, not VST) wouldn't automate, but when I upgraded to version 3.5, automation worked as expected.

I also checked Sonar's ability to store and reload presets in wrapped VST Instruments. While I didn't assess every possible combination of synthesizer and wrapper, I also didn't encounter any problems with those I tested.

The knobs in Sonar's included DXi DreamStation automated with easily edited controller data. The DXi version of FM7, however, wouldn't automate. Onscreen slider moves were not recorded into its MIDI track. I had no trouble adding MIDI controller envelopes to Sonar tracks, though, and driving FM7's limited set of MIDI controller inputs with them.

I had various problems with the wrapped version of the Waldorf PPG Wave 2.V synth. The panel appeared in Sonar, and I could play the PPG live from my MIDI keyboard, but every time I tried to record a MIDI track for it, Sonar's audio output shut down. That happened with the DirectiXer conversion and with the FXpansion conversion. Cakewalk tech support suggested choosing Alternative Window Sizing Method in DirectiXer. After I did that, the PPG worked as expected. For some reason, the FXpansion conversion worked the second time as well.

DirectiXer's performance with converted VST Instruments was not perfect. Steinberg's The Grand converted, responded to MIDI input, and allowed a MIDI track to record and play back. But Waldorf Attack consistently crashed Sonar when converted by DirectiXer. FXpansion converted Attack without errors, and I was able to edit its sounds, record a track, save and reopen my song file, and so on.

Sonar had no trouble automating the parameters of converted VST plug-ins. However, when I used SuperCamelPhat 2.0 to process the output of Attack (both having been converted by FXpansion), Sonar exhibited some instability. Sometimes when I started playback, the CPU meter jumped up to 80 percent, and playback wouldn't start. When I clicked on the Start button a second time, the two plug-ins worked together. I tried removing SuperCamelPhat from the Attack track and using it to process a stereo audio track. In that configuration, there was no CPU spiking.

A few days later, the FXpansion conversion of Attack decided to be a little more cantankerous. After instantiating it, I could play it from my keyboard at first, but each time I double-clicked on the DX rack to open Attack's edit window, Attack's audio output went away. I had to click on Sonar's audio engine button twice to get the audio started again. When I instantiated the PPG in the same song, CPU usage suddenly shot up to more than 80 percent and stayed there, even though I was playing only one or two notes on the PPG and none with Attack. When I quit the song and reloaded it, however, CPU usage was down around 6 percent, where it belonged. (According to Cakewalk, performance might be improved a bit by slightly increasing the Latency slider setting or by changing the parameter setting StopIfStarved=n Aud.INI.)

The Steinberg Karlette tape-delay emulator wrapped and worked in Sonar, but I was unable to get it to sync to Sonar's tempo. DXi2 supports MIDI Clock sync, so it's difficult to say exactly where the hang-up was.


Sound Forge 6.0 readily used VST effects converted by all three wrappers. It provides a dialog box with which you can add the effects of your choice to the DX Favorites menu. The Preview button in the effect's edit window lets you hear what the processed file will sound like. When the parameters are set to your satisfaction, click on OK and your file will be processed.

Sound Forge affords no real-time control over the effects while the file is being processed. In fact, processing isn't even a real-time event; it occurs silently in the background. Sound Forge 6.0 does, however, include a new Audio Plug-In Chainer window that lets you link several DirectX plug-ins in a single chain. It works “nonmodally,” so you can preview and change the output volume of any effect without leaving the plug-in interface.

Also, Sound Forge can't attenuate the input to an effect; it sends files to the effect at full level. If the effect boosts some frequencies (as is emphatically the case with SuperCamelPhat), and if the effect doesn't have its own input attenuator, the output can easily overload. The work-around is to reduce the level of the file first, and then process the reduced audio as a second edit. Because Sound Forge has multiple undo and redo capability, this is only time-consuming, not difficult.

Going the other direction, the DirectX effects bundled with Sound Forge can be used in other hosts but can't be automated. (Sonic Foundry's Acid Pro 4.0 does provide DX automation and supports VST Instruments, and Acid's automatable DX effects work in Sonar.)


Fruityloops will run both DX and VST plug-ins without a wrapper. The VST parameters that I tried automated in Fruityloops, but the DX versions of the same plug-ins were less consistent. According to Image-Line, DirectX 8 plug-ins that publish their parameters to the DX host can be controlled.

Fruityloops also could instantiate both DXi and VSTi synths. Not that I don't appreciate the Fruity synths, but I love being able to expand my palette. Waldorf Attack (directly as a VSTi, not wrapped as a DXi) fits well with the Fruity “all rhythm patterns, all the time” vibe. I was able to automate Attack's knobs with the mouse, but right-clicking didn't open Fruityloops' Event Edit window. Turns out, that window is accessed from a drop-down menu. Some of the VST Instruments I tried allowed parameter automation, but some, such as Spectrasonics Stylus, didn't.

The DreamStation DXi2 synth, which ships with Sonar, loaded into Fruityloops, but it wouldn't make a peep. The excellent DR-008 percussion-oriented DXi2 synth loaded and played, but I couldn't get its knobs to automate.

The Waldorf PPG Wave 2.V synth (instantiated as a VSTi) loaded into Fruityloops, but while it made its usual array of way-cool sounds, it also gave me dropped notes and stuck notes while playing a fairly simple pattern.


All three wrappers did the job, with some individual variations from plug-in to plug-in. When it came to automation, I was able to control some parameters some of the time, but trying dozens of different combinations and struggling to figure out what was user error and what was genuinely a limitation of the software left me echoing the bewildered words of Rodney King, “Why can't we all just get along?”

Why do the large manufacturers force musicians and plug-in developers to jump through hoops? Why can't they just agree on a single plug-in standard? According to Cakewalk, there are legitimate technical reasons why the company prefers not to support VST. As explained to me by Cakewalk's technical representative, the main issue is how the host application prevents processing conflicts in a multithreaded environment. Different approaches to multithreading in various host applications make universal plug-in compatibility extremely difficult.

Although I'm not a software engineer, I found Cakewalk's explanation to be revealing. From the outside, it may appear that the wrapper developers are solving a problem that should never have arisen in the first place. But given the complexity of real-time audio software, getting all of the companies to implement a single plug-in standard might be prohibitively expensive, even if it were technically and politically feasible.

Oh, well. It's a nice dream.

Jim Aikinhas been writing about music technology for more than 25 years. He is currently working on a book about software synthesizers.