Managing Your PC Plug-ins More Effectively

Software plug‑ins are now available as channel Inserts, Global send/return effects, and as Master effects, so it makes sense to know how best to manage them.

There are now hundreds of software processing plug‑ins available to PC musicians, but they come in various types and each behaves slightly differently. Martin Walker examines the various ways to install, manage and automate them, and the problems involved in managing presets.

On the PC, there are now three main plug‑in formats. Microsoft's DirectX support is provided in nearly all modern audio applications, while VST‑compatible plug‑ins are now supported not only by Steinberg's Cubase and Cubasis VST, but also Emagic's Logic Audio range, and software synthesizers like Software Technology's VAZ Modular. The original VST plug‑in specification (version 1.0) has been superseded by VST 2.0, making it possible for plug‑ins to receive and transmit MIDI as well as just audio. This makes it easy to sync processing plug‑ins to MIDI clock, so that (for example) delays can be created that operate your song's tempo — but perhaps the best‑known use for this new development is in the recently arrived VST Instruments. These are 'virtual' synths driven by MIDI data inside the PC, and which output audio via the host application. In fact, PC‑based VST Instruments and VST plug‑ins have exactly the same format — a single DLL file — but declare their capabilities to the host application, so that when you launch a host application such as Cubase VST they either get placed in the plug‑in list or the synth rack.

The third type of plug‑in is specific to a particular application. Emagic, for instance, first included their own brand of internal plug‑ins in Logic for PC from version 3.0, later relented and included support for DirectX in version 3.5, and eventually for VST plug‑ins in version 4.1 onwards. Because they have been specially written to interface directly with Logic, the bundled Emagic plug‑ins (34 are supplied with v4) can't be used with any other MIDI + Audio sequencer, and nor can Emagic's new ES1 synth and EXS24 sampler instruments. However, they all have slightly lower CPU overhead when used in Logic compared with VST or DirectX effects.

Nowadays, as well as commercial plug‑ins, there are a wide variety of useful designs available free or for a modest shareware payment (see this month's Net Notes, on page 232 for locations on the Internet where free plug‑ins can be obtained). Plug‑ins have certainly revolutionised much music‑making, but you will get much more out of them if you understand the different types and how your computer works with them. This month I'm looking at where best to install them, how your PC's Registry is involved, and how to ensure a clean uninstall if you later want to remove them. I'll also cover the process of automating different types of plug‑in, and explain the various difficulties you can encounter when loading and saving effects presets.

Installing VST Plug‑ins

The latest version of Cubase VST (3.71) lets you organise your VST plug‑ins more effectively into nested folders, so that you can sort them by effect type or manufacturer to keep your scrolling list more manageable.

VST plug‑ins (and VST Instruments) are very easy to install, since they normally consist of a single DLL file. All you do is drag or copy this file into a folder called 'Vstplugins', and the next time you launch your host music application you should find an new entry in its list of available plug‑ins.

However, it is the location of the Vstplugins folder that is important, and merits discussion, as its location depends on which host application you are using. If you're running Emagic's Logic, the program will only offer you the use of VST‑format plug‑ins if the Vstplugins folder containing them is itself located inside the main Logic application folder. Logic also doesn't create the Vstplugins folder when you install it — you have to do it yourself.

Steinberg, on the other hand, have added an option in v3.71 of Cubase VST to create a common Vstplugins folder outside the Cubase application folder. Given the increasing number of other applications that support VST‑compatible plug‑ins, this makes a lot of sense. Also, if you ever uninstall it, Cubase VST will automatically remove any plug‑ins installed in its 'internal' Vstplugins folder, whereas any applications found in an 'external' folder will be queried during an uninstall.

I discussed this subject in more detail in PC Notes in SOS February, but in essence you choose a location for the external folder during installation of Cubase v3.71, and then install all plug‑ins into this folder rather than the one inside the Cubase folder. For safety's sake, you should move any plug‑ins currently in the old Cubase folder to the new one, so that all your plug‑ins are in one place, and also so that your entire range of Vstplugins is visible to other applications as well. If you're using Logic and Cubase on the same PC, you'll have to designate the internal Logic folder as the external Cubase one when you install Cubase, as the Logic plug‑ins folder cannot be located outside the main Logic folder. If you have already installed both applications, you can manually redirect the existing file path for Cubase, but this does require a
Registry tweak (make sure that you back the Registry up before trying this out!). First run the Microsoft Registry Editor (you can do this by typing 'regedit' as a Run command from the Start section of the Taskbar) and then find the entry HKEY_LOCAL_MACHINE\SOFTWARE\VST\VstPluginsPath. You can then Modify this entry to point to the plug‑ins folder used by Logic Audio.

Another feature recently added to Cubase VST is the ability to install plug‑ins in nested folders inside the main Vstplugins one. You can add these at any time, since Cubase looks inside every folder it finds each time you launch it. This means you can tidy up a long unwieldy scrolling list of plug‑ins into folders (see the screenshot above), but care is needed, as not all VST plug‑in host applications can 'see' plug‑ins in nested folders.

Installing/Uninstalling DirectX Plug‑Ins

Some DirectX plug‑ins are not provided with a comprehensive uninstall option, but thankfully various freeware utilities such as DX‑uninstaller from Vincent Burel and DXMan from AnalogX let you remove all traces of them from your Registry.

DirectX plug‑ins can be installed into any folder you choose, but they also need to be properly registered by Windows. This is normally taken care of by their installation routine, usually named setup.exe. Running this routine will not only install all the files needed into your choice of folder, but also add the required lines to your PC's Registry to make sure that the plug‑in is correctly logged.

Once a new DirectX plug‑in has been properly installed in this way it should automatically appear in the list of options inside all compatible host applications the next time you run them. Some don't refresh their plug‑in list automatically every time you launch them, however — in Cool Edit Pro, for example, you have to do this manually by clicking on the 'Refresh This List' option at the bottom of the drop‑down DirectX options in the Transform menu.

Sadly, some DirectX plug‑ins are not supplied with an Uninstall option, so that even if you delete the associated files, the plug‑in will still appear as an option inside applications. One way to ensure a complete uninstall is to monitor the install routine with a utility like CleanSweep. If you use this application to uninstall the plug‑in, all traces of it will be removed, and the necessary modifications and additions to the Registry will be made automatically. However, even without such an application, you can still remove all traces of unwanted plug‑ins using one of the freeware utilities written by generous developers that scan the Registry for plug‑in entries, and then let you delete references to any whose files have already been deleted.

The simplest of these is Vincent Burel's DX‑uninstaller, but DXMan from AnalogX is rather more comprehensive. This lets you remove entries by selecting one of them and then clicking the 'Remove' button, but the window also the name of the associated file, and whether or not the files actually exist on your hard drive. The Properties button launches the plug‑in window (if there is one), while the Info button shows how many inputs and outputs it has. You can also register a plug‑in by dragging its DLL file into the DXMan window.

Automating VST Plug‑ins

This is how to set up a DirectX plug‑in with VST 2.0 MIDI Automation inside any host application using Hubi's Loopback. Select a suitable Hubi node such as LB1 as the MIDI input in the plug‑in, along with your choice of MIDI channel, and then create a MIDI track using the same channel in your sequencer, and select LB1 as its MIDI output. Any MIDI controller data that you record into this track will then be routed to the plug‑in to automate its controls.

Most MIDI + Audio sequencers provide volume and pan automation as standard these days, but in many cases it is also possible to automate effects. Cubase VST lets you automate volume, pan, mute, solo, and EQ parameters, as well as all the settings of your VST‑compatible plug‑ins. All you need to do is click on the Auto Write button for any subsequent control moves to be recorded — as soon as you do this a new Audio Mix track is automatically created to store the automation data. Activating Auto Read will ensure that the same moves are replayed during playback, and you can override the current settings at any time by grabbing the appropriate control with Write mode activated and moving it elsewhere.

DirectX Automation

The latest version 2.0 of FXpansion's VST to DirectX Adaptor even lets you automate VST plug‑ins inside non‑VST‑compatible host applications like Cakewalk Pro Audio. Here the utility has been routed into an audio track, and then automation for Prosoniq's freeware NorthPole filter has been recorded into a separate MIDI track, and routed into the Adaptor. Clever stuff!

Sadly there is no such simple standard for automating DirectX plug‑ins, and for this reason some developers have only released VST versions of their plug‑ins (like Waldorf's excellent Dpole filter). However, some developers have written their own MIDI‑controlled automation for DirectX plug‑ins — each parameter uses a different MIDI controller number, and you can then record the controller data into a separate track in your sequencer to move the appropriate plug‑in controls in real‑time. Examples of plug‑ins with this facility include FXpansion's Series One effects, Digilogue's entire Blue‑Line range, and the DSP.FX range.

The simplest form of MIDI plug‑in automation is the ability to read incoming controller data on different MIDI channels, and this is the type supported by the FXpansion plug‑ins. Although you can dedicate a hardware MIDI input to automation duties, the most elegant routing solution involves the freeware utility Hubi's Loopback, which is covered in more detail in the PC Musician feature in SOS November '99. This multi‑client utility creates up to four 'nodes', normally labelled LB1, LB2, LB3, and LB4. Each of these can handle up to four simultaneous In clients and up to 10 simultaneous Out clients. After you have installed it you should see these additional entries in your list of MIDI inputs and outputs.

To route the output of your sequencer to the input of an FXpansion DirectX plug‑in for automation, you need only a single node. Choose this as the MIDI Input device on the plug‑in, and a suitable MIDI channel, and then make sure that you choose the same node as a MIDI output for the track you are going to use for automation inside your sequencer (you can see these routings in the screen shot above). Then any MIDI controller data that you record into this track will be sent direct to the plug‑in. Details of which controller numbers are used for each plug‑in parameter are detailed in the plug‑in's documentation.

Digilogue's Blue‑Line plug‑ins can also read incoming controller data. However, these plug‑ins also support write automation, so that you can move the plug‑in 'front panel' controls to generate MIDI controller information that can be recorded in your sequencer. This time you will need to activate a separate MIDI output node to send this data to, and choose the similarly named node as input in your sequencer. The only problem I found with this Digilogue write automation was that only three of my MIDI ins and outs appeared in the drop‑down automation boxes — so be aware that if you have more than three, some of your MIDI devices may not be visible for selection.

Given that there are now so many freeware VST plug‑ins available, it made sense for an enterprising developer to find a way to use them with host applications that only supported DirectX ones. FXpansion's Angus Hewlett rose to the challenge, and the shareware VST to DirectX Adaptor was born, followed more recently by the freeware VST‑DX Wrapper from SpinAudio. Version 2.0 of VST Adaptor also lets you automate VST plug‑ins when running them in a DirectX‑only host application (see screenshot on page 112). The automation may be a little jerky or late, depending on the size of your audio buffers, but it's a huge improvement over no automation at all!

Preset Management

Loading and Saving plug‑in presets is normally handled by the host application. In the case of VST plug‑ins you have two options — you can either Load/Save individual effects in the FXP file format (ie. files that end in '.fxp'), or Load/Save complete banks using FXB‑format files (which end in '.fxb'). The number of presets in a Bank isn't fixed, and I have plug‑ins in my collection that have two, four, 16, and 32 presets. File sizes also vary depending on the number of parameters that need to be saved for each preset. The FXP/FXB preset management system works well, and is fairly universal among VST‑compatible host applications — for example, you can save a bank of presets in Cubase and then load it inside VAZ Modular.

DirectX plug‑ins normally also rely on the host application to control preset management, but here every developer seems to re‑invent the wheel. Your preset data may be saved in a variety of places, either as a unique SET file for each plug‑in bank in the case of Wavelab for example, or grouped together in a single file — the system used by both Syntrillium's Cool Edit Pro and Sonic Foundry's Sound Forge, for instance. The main problem with these variations is that if you create a killer effect in one application, there is no easy way to get at it inside another (more on this later)

To avoid such problems, some DirectX plug‑in developers, like Digilogue with their Blue‑Line range, provide Load/Save buttons on their plug‑ins that employ the same FXP format as Cubase VST itself. Waves, meanwhile, add their own Load/Save buttons and PST file format to the plug‑ins themselves. This means that any presets that you save when working inside one application will also be available from within another one, although you do get the confusion of having two sets of preset buttons — one provided by the application (which you should ignore), and another by the plug‑in.

Emagic's Logic series treats all plug‑in types in the same way — each plug‑in has its own unique folder for presets inside the main Logic 'Plug‑in Settings' folder. Each preset is saved in a separate file, and the first time you save one a new folder is created with the name of the plug‑in if one doesn't already exist. This approach does keep all your presets neatly in one place, but of course it does create many tiny files, some of which may only be a few bytes in size and waste hard disk space.

Creating Your Own Presets

As with hardware effects units, many software plug‑ins are shipped with a series of default settings. These 'read‑only' presets, known variously as Factory, Static or ROM presets, can theoretically be available from within all applications, as they are permanently stored in the preset code itself. Some plug‑ins which include them are the TC Works Native Bundle and Native Essentials packs, Arboretum's Hyperprism bundle, and the Waves Native Power Pack. The beauty of these is that you can select a suitable factory preset, modify it to suit your song, and then save it as your own preset in whatever format is used by the application you are using — but sadly not all factory presets appear in all applications.

Those presets handled by the plug‑ins themselves appear in every host application; these include products from TC Works and Waves. However, the DirectX Static presets that appear inside some applications in a drop‑down scrolling list at the top of the plug‑in are currently ignored by both Cubase VST and Logic Audio. Plug‑ins with these presets include those from Arboretum, Cakewalk, QTools, and Sonic Foundry.

Sharing Presets Between Applications

As explained earlier, exchanging plug‑in presets between different VST host applications is not plain sailing. Wavelab and Cubase VST do have a special relationship, and VST‑compatible plug‑ins appear in Wavelab with Cubase‑style preset management. However, since DirectX plug‑in preset management is handled differently in each and every application, you can't load DirectX presets saved in Wavelab into the same plug‑in when it is running inside any other application (including VST). This sort of problem will face anyone who uses more than one audio application with their plug‑ins.

The only practical solution for anyone in this situation is to launch both applications (for example Wavelab and Cubase), open the same plug‑in in both applications, and then for each and every preset already created in Wavelab, carefully set each plug‑in control in the Cubase window to the identical value by hand, and then save the entire bank in Cubase FXB format. Although tedious, this technique can still save a considerable amount of time over creating new presets from scratch, although it's only feasible with plug‑ins whose parameters provide numeric readouts — accurately reproducing settings graphically would be almost impossible.

A Common Approach?

Since so many musicians have more than one VST‑compatible audio application, it would seem sensible for developers of host applications to decide on a standard method of DirectX preset management, so that musicians can access their presets from any of them. Sonic Foundry have already suggested a standard way to load and save preset data using the Registry, but the success of this approach relies on other developers following their suggestions. Apparently Sonic Foundry's own Sound Forge v4.5 and Acid both take this approach, and Software Technology's VAZ Modular has also adopted it. However, it is not currently used by other host applications such as Cubase VST, Logic Audio, and Cool Edit Pro, and even though Cakewalk's audio applications do seem to store their presets in the Registry, they use a different method, as Cakewalk‑hosted presets are not available to other applications.

Even if Sonic Foundry's suggestion were universally adopted, I'm not convinced that it's the ideal solution. Storing preset data inside the Registry is certainly one way of making it available to any application without having to point to a particular folder, but the Registry would grow alarmingly if this became the universal approach. Also, I don't like the idea of hours of effect‑creation work being stored in a single system file that may occasionally get corrupted — I'd be far happier to have all my presets sitting in a single folder for easy backup onto CD‑R or Zip cartridge.

However, the main limitation is that musicians can't swap banks of effect presets if they are stashed away as part of the Registry. The fact that some applications already store their presets in the Registry, or in one of many incompatible preset bank formats is what prevents the free interchange of effect banks on the Internet. Lots of musicians are asking for such a service, but currently a bank of useful effect settings would have to be supplied in each of the formats for different host applications. This is where Waves, with their PST format, have a head start — banks of presets are available in this format on their web site for the majority of their plug‑ins.

Of course, software developers could solve this problem once and for all by thrashing out an agreed standard format for saving and loading preset plug‑in data banks, but until this happens, we need an automated way to convert one format into another, so that at least we can convert banks created in one application into ones that can be loaded into others. It ought to be fairly easy for a programmer to extract and remap the data for each preset in this way, but I haven't come across any such utility to date. I'll let you know if I do.