Tips & Tricks
Technique : PC MusicianThere 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 be
Host Applications
There are now quite a few compatible applications for hosting real-time plug-ins. In general, those that support VST plug-ins also support DirectX, but many are DirectX only.
VST SUPPORT
Emagic Logic Audio Silver, Gold, and Platinum v4.1 and later.
Software Technology Vaz Modular v2.0 and later.
Steinberg Cubase and Cubasis VST, Wavelab v2.0 and later.
DIRECTX SUPPORT
CMS Cakewalk Pro Audio and Cakewalk Home Studio v6 or later.
SEK'D Samplitude Studio and Samplitude 2496 v5 and later.
Sonic Foundry Sound Forge v4.0 and later, Acid Pro, Vegas Pro.
Syntrillium Cool Edit Pro v1.1 and later.
st 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
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
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
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
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
Reducing Unnecessary Plug-In Clutter
If you have a VST and DirectX version of the same plug-in, always use the VST one if possible, since this will have slightly lower CPU overhead, as well as being capable of automation. Some developers provide multiple versions depending on where in the audio chain they are to be used. TC Works, for instance, provide three versions of their TC Native Reverb plug-in: a DirectX one, and VST and VST Master versions. If you are going to use the VST ones then the Master version is intended for use as an insert effect, and therefore has a wet/dry mix control, while the other one consumes slightly less CPU power by removing this control, for use with send/return routing where the mix is taken care of elsewhere.
Some applications have software plug-in managers, which let you decide for yourself which plug-ins will appear inside them. Logic Audio's Plug-In Enabler utility operates with both DirectX and VST types, Cubase VST has a 'DirectX Plugins' option in its Audio menu, and Wavelab provides a comprehensive Plug-Ins Manager. Using these utilities, you can also remove entries that are not suitable for the host application -- for example, I disable Cakewalk's Buffer Size Matcher and Sonic Foundry's Plug-In Chainer inside both Cubase and Logic, since these are only really of use inside their respective host applications.
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.
Published in SOS June 2000
No comments:
Post a Comment