CHOOSING & USING PC PLUG-INS

Choosing & Using PC Plug-ins

Published in SOS July 2002
Printer-friendly version

Technique : PC Musician

Like Logic Audio and now Wavelab 4.0, Cubase 5.0 offers bundled application-specific plug-ins.

Software effects and instruments are becoming ever more important in music production -- but what are the pros and cons of the innumerable formats available, and which host applications can use them?

Since I last wrote about plug-in formats in SOS June 2000, the landscape has changed considerably. Not only is there a new breed of DSP 'powered' plug-ins available, but Cakewalk's Sonar has also introduced two completely new formats in the shape of DirectX 8 plug-ins and DXi soft synths. It can sometimes be confusing trying to determine whether or not a particular product is compatible with your choice of MIDI + Audio sequencer, and to make matters worse, some plug-ins can be installed in multiple formats. If you run Cubase VST and Wavelab, for instance, and install a new plug-in, is it best to choose the Wavelab, VST, or DX version? If your sequencer only supports DX plug-ins, is there a way to run VST ones, and if so, does it impose any restrictions or extra CPU overheads?

The first plug-ins to appear on the scene used Microsoft's DirectX technology, originally pioneered way back in 1997 in products like Cakewalk's Pro Audio 6.0, Sonic Foundry's Sound Forge 4.0a, and Steinberg's Wavelab 1.6. DirectX plug-ins can now be launched from inside nearly all music applications that have any sort of plug-in capability, and usually have the advantage of a set of built-in presets that can't get separated from the plug-in. However, they can be annoying for several reasons. First, unlike some other formats, they require a full installation (just like an application), which must also supply details to the Windows Registry before the plug-in can subsequently appear inside compatible music applications. This often means that they end up scattered to the four corners of your hard drive in their own dedicated folders, making them harder to keep organised. Second, in most cases it's not possible to automate their parameters.

Cakewalk's flagship Sonar application introduced a new breed of DX8 plug-ins that went beyond the older DX format, and provided automation and soft synth functions previously only available to the VST format.

The other major PC plug-in format is VST, introduced by Steinberg for Cubase VST and now supported by most other music host applications. Steinberg maintained that VST plug-ins were more efficient than DirectX ones, since they didn't require an outer layer of general code, but given the speed of today's processors, this difference shouldn'tbe too significant (more on this aspect later on). In the majority of cases installation of VST plug-ins is considerably easier than that of their DirectX counterparts: you just drag the VST plug-in file into a central folder named Vst Plugins, and it appears automatically to all VST-compatible applications. Cubase users will normally find this inside the Program Files/Steinberg folder, while Logic Audio users need to create one inside their main Logic folder.

Cubase version 3.7 introduced the VST 2.0 plug-in specification, which let plug-ins receive MIDI data, so that their parameters could be automated. This also paved the way for VST Instruments -- essentially audio plug-ins that generate their data solely based on MIDI information such as Note On and Off commands.

Such is the popularity of VST plug-ins that even hardware manufacturers have since supported this format. With Universal Audio's UAD1 DSP card, the Lexicon Studio and Core soundcards, and Creamware's Pulsar XTC, the computations are all carried out by hardware DSP chips running completely different code from the native PC processor, but this is transparent to the user: the effects are all launched and used from within a VST-compatible application just like any other plug-in.

Alongside the DX and VST formats, Wavelab 1.6 also included its own brand of plug-ins which showed up only inside Wavelab. This trend has continued with more recent versions of Cubase VST and Logic Audio, both of which are now bundled with comprehensive sets of proprietary plug-ins. These may have a slightly lower CPU overhead than generic plug-ins, since they can be more closely integrated with their particular host, although this may not always be the case if they rely on extra code to prevent them being used in other applications.

A major update to the DirectX plug-in format arrived in Cakewalk's Sonar. Cakewalk's Pro Audio sequencer range already supported DirectX plug-ins, but Sonar capitalised on the new functions provided by Microsoft's DirectX version 8.0 to add automation to DirectX audio plug-ins. Moreover, in the same way that the VST 2.0 standard enabled audio plug-ins to become VST Instruments, DX8 also made the DX Instrument (DXi) possible. There was an interim period during which DX8 wasn't recommended by some developers such as Steinberg, since it changes a lot of fairly low-level system files and gave a few musicians compatibility problems. However, these have now been resolved, so there seems little reason to be cautious.

With one of this handy collection of 'wrapper' utilities you can turn a VST effect into a DX or DX8 one, and even a VST Instrument into a DX Instrument.

DX instruments have recently been given more features by Cakewalk in Sonar 2.0, with the introduction of the DXi2 standard. This adds sample-accurate timing and the capability to have multiple outputs like VST Instruments, which makes multitimbral soft synths and drum machines easier to set up. It also allows MIDI output from a MIDI plug-in or DX Instrument to be sent back to the host.

There are a few differences between the VSTi and DXi formats. VST 2.0 apparently restricts the length of SysEx messages to just a few bytes, whereas a DXi supports full-length SysEx messages from the host to the synth and vice versa. This does make it impossible for a VSTi to receive SysEx bulk dumps via MIDI from a VST host application, but since most of them also let you import SysEx as a proprietary file load, this aspect isn't likely to worry many musicians.

Annoyingly, VST Instruments don't provide the mechanism for a synth to report bank names, patch names, note names or controller names, all of which are supported by DX Instruments. One example of this limitation is that some soft synths implement their own load/save routines primarily for running in stand-alone mode, but if you use these functions when running as a VSTi, the updated names don't get correctly reported to the VSTi shell. For instance, if you change patches in NI's Pro 52, the new patch name will appear if you use the VSTi shell buttons or drop-down menu, but won't be updated if you change patch using the front-panel Programmer buttons.

Another limitation of the current VST 2.0 standard is that its windows cannot officially be resized. This restriction is annoying with products like Reaktor, whose synth panels designs are available in a huge number of shapes and sizes. If you use the DXi version of Reaktor, its window is fully resizeable.

Nearly all VST-compatible host applications also support DirectX plug-ins, but the converse is not true. Since so many VST plug-ins exist, it's hardly surprising that some bright spark came up with the idea of a 'wrapper' that makes a VST plug-in look like the DX version, so that both types can be used with such applications. That bright spark was Angus Hewlett of FXpansion (www.fxpansion.com), whose VST-DX Adapter was the product that started the ball rolling. From version 3 this has allowed both VST plug-ins and VST Instruments to be used with DX8 automation inside Sonar. Version 4.0 is already at the beta testing stage, and will incorporate multi-output support for the DXi format, as well as providing MIDI learn and plug-in organisation functions. The Standard Edition is $60, while the Lite Edition is just $30.

The second developer to introduce a wrapper was Spin Audio (www.spinaudio.com): the Lite version of their VST-DX Wrapper is a completely free download. VST-DX Wrapper Pro adds individual wrapping of multiple plug-ins, plus integration with Spin Audio's SkinRack Wizard. Currently the Spin Audio VST-DX Wrappers only support the VST 1.0 standard, so don't give users MIDI automation or the ability to run a VST Instrument as a DXi, but Spin Audio are working on version 2.0, which will add these features as well as built-in skin racking. The Pro version is just $25, or $50 when bundled with the current SkinRack.

The latest release is Tonewise's DirectiXer (www.tonewise.com), which supports both VST plug-ins and instruments and already supports the multiple outputs provided by DXi 2.0. It's currently at version 2.0, requires DirectX 8, and supports Windows 98SE, ME, 2000 and XP. For plug-ins featuring more than one stereo output, you can configure your VST outputs as any combination of stereo and mono DXi2 individual outputs. Even if your host application is restricted to DXi 1.0, you can use DirectiXer's Master Mix functions to submix any combination of outputs to feed a mono or stereo configuration. Registration for DirectiXer is just $39.

When using a wrapper, you shouldn't lose access to any presets supplied with the VST plug-in version. Tonewise offers individual buttons that let you load and save both presets and banks in the original FXP and FXB formats, while FXpansion provide a Tools button with these options in a drop-down list, as well as a handy Randomise function. Spin Audio don't implement such extra facilities in their simpler VST-DX Wrapper, although you can use those of the host application.

All the wrappers discussed here place extra entries in your Registry for each wrapped plug-in, but provide reset functions so that you can at any time strip one or all of them out and return the Registry to its previous state. However, should you wish to uninstall the wrapper for any reason, make sure you use these functions to unregister the plug-ins beforehand, as otherwise all these entries will be left cluttering up your Registry for ever.

Given the host of VST plug-ins and instruments on the market, written by a huge number of different developers, it's inevitable that a few may cause problems when enclosed in a wrapper. It's well worth downloading demo versions of each wrapper to see which one you prefer, and to test out compatibility with your plug-in range. To cope with rogue plug-ins, the more advanced wrappers from FXpansion and Tonewise offer a set of options that you can change for individual products. For instance, some plug-ins don't show their interface in full when wrapped, displaying instead just part of the front panel. Tonewise have an Alternative Window Sizing option to combat this, while FXpansion provide Editor Size (X) and (Y) parameters to manually force any panel size.

These wrappers should also in general work with 'powered' plug-ins such as those provided with Universal Audio's UAD1, allowing such hardware can be used within non-VST applications such as Sonar (although UA are in any case working on a DirectX version of their software). FXpansion's VST-DX Adapter offers improved performance with Universal Audio's UAD1 from version 3.3 onwards. However, the added complications of sending data to and from hardware buffers can give rise to timing problems once you start using several such plug-ins simultaneously, so if you're using Sonar, don't splash out on expensive DSP hardware before you check out wrapper capabilities carefully with the developer. Also, note that wrappers won't work with application-specific plug-ins such as some of those bundled with Cubase 5.0, Fruity Loops, Logic Audio and Wavelab.

Some musicians are worried that adding a wrapper will give increased latency over and above the existing soundcard value, but this shouldn't be the case: the wrapper simply adds some extra code around the original plug-in that takes a tiny amount of extra RAM and a negligible amount of time to run. However, a few rare exceptions exist, notably with plug-ins that react badly and crash when run with a variable buffer size. This often happens with a DX host when used in a playback loop, so if one of your plug-ins works fine except when you set up a loop, you'll need to activate FXpansion's Fixed Size Buffers option for that plug-in, or the Tonewise Use Equally Sized Buffers option, both of which introduce a small latency -- in the case of DirectiXer, this is quoted as 64 samples, which is just 1.45mS at a sample rate of 44.1kHz. You'll need to use these options with some Native Instruments plug-ins including Spektral Delay, B4 and Pro 52.

Although DX8 automation has now arrived for Sonar, MIDI-automatable VST 2.0 plug-ins have been around a lot longer, and many more are available. Several proprietary solutions also exist for DX plug-ins: FXpansion's plug-in range and the DSP.FX series both provide dedicated functions that allow them to receive MIDI data from your choice of MIDI port, independent of the host sequencer. FXpansion also offer MIDI automation with their VST-DX Adapter Lite when running VST effects plug-ins inside DX-compatible host applications, and the Standard Edition extends this to VST Instruments, which can therefore run inside Sonar as DX Instruments. DirectiXer also supports parameter automation recording and playback along with MIDI NRPN automation, which may be more useful where an instrument isn't using a dedicated audio track in the host application. Version 2.0 now also supports song tempo information to plug-ins, so that they can be sync'ed together. Since DXi hosts only provide song information to instruments, and not to plug-ins, there's a Use Instrument Mode option to enable effect plug-ins to access this as well if appropriate.

Some VST plug-ins may cause unexpected problems when run in a wrapper, but there are often special options (such as these in DirectiXer) to combat the problem.

VST automation of both audio plug-in and VST Instrument parameters is done using MIDI messages. This means that all parameter changes consist of instantaneous jumps to the new value, and that parameter resolution recorded within the sequencer is limited either to the seven or 14 bits offered by MIDI Controller information, or possibly a 16-bit SysEx value. If you're using a seven-bit controller restricted to 128 values, you may notice steps between values on some plug-ins. Real-time knob tweaking, by contrast, apparently sends 32-bit values -- although once again I've certainly come across some plug-in designs that implement only 128 stepped values.

DX8 automation has the advantage of using shapes to define parameter changes over time, which are described by a start time and value, an end time and value, and a shape joining the these two points. This data is all sent in high-resolution 32-bit float format, as are real-time tweaks, although of course if you're using a hardware MIDI controller to generate this data, it will still normally be restricted to seven- or 14-bit MIDI Controller resolution. DX8 plug-ins can each specify their own preferred automation time format, either in units of 100 nanosecond 'reference times', or in musical time of arbitrary PPQN precision.

There's absolutely no basic coding difference between VST and DX plug-ins apart from the automation. However, given that VST plug-ins are mostly designed to run on both the PC and Mac platforms, and that DirectX plug-ins only run on Intel-compatible hardware and Windows, some developers writing only DX versions may be able to optimise their code more efficiently.

In general, if one of your plug-ins is supplied in multiple formats, you should install the one that most closely fits your host application, since this is likely to take the lowest CPU overhead. For instance, anyone using Cubase or Logic should use VST plug-ins where possible in preference to DX ones, since DX plug-ins run inside these applications with their own internal 'wrapper'. Sonar users should ideally use DX8 versions, although these are still in comparatively short supply. Failing this, if a plug-in is available in both VST and basic DX versions, Sonar users will probably find the DX one takes slightly less CPU, but using the VST version with either the FXpansion or Tonewise wrappers will let you automate the controls, which is a significant advantage. Internal wrapping is utilised more often than many people realise, and many of the currently available third-party DX Instruments are actually VST Instruments running under proprietary VST-DX wrappers. Given that writing a wrapper isn't a trivial exercise, this may mean in some cases that running a VSTi with one of the now highly refined third-party VST-DX wrappers may prove slightly more efficient than using the supposedly native DXi version.

However, it's important not to get bogged down in details, and to keep the figures in perspective. To find out what overheads were imposed by the various wrappers, I used Wavelab 4.0 as a host, since it provides an accurate readout of CPU overhead. After exhaustive tests using a variety of VST plug-ins in their standard and 'DX wrapped' versions with FXpansion's VST-DX Adapter, I eventually measured its overhead at a tiny 0.4 percent of my Pentium III 1GHz processor. I then used the same techniques within Sonar to get a feel for how much overhead was being added to wrapped VST versions of plug-ins compared with native DX versions where available, and again this was very small at about 0.7 percent. Unless you are running dozens of simultaneous wrapped plug-ins, such tiny overheads simply won't be noticeable.