PC AUDIO 117
8 September 2016
Where should you install your VST plug-ins? Fear not, as we explain VST2 and VST3, and how to sort out any confusion.
Column: Martin Walker
Most PC musicians could not imagine a world without VST real-time plug-ins. I was already writing about music technology in the years BP (Before Plug-ins). While there were various off-line effects available in WAV file editors for effects such as reverb, filtering and echo, alongside more standard treatments such as normalisation, fade-ins and fade-outs, their audio quality was rarely on a par with the most budget hardware effects units available at the time. Furthermore, you had to wait at least several seconds before all their calculations had finished before you could hear the sonic results. This all changed in late 1996, when after the first audio plug-ins were released utilising Microsoft’s ActiveMovie technology (subsequently renamed DMSS, or DirectX Media Steaming Services), followed by Steinberg’s very own VST (Virtual Studio Technology) interface specification in 1996. Steinberg’s release of Cubase 3.02 included the first VST format plug-ins, but by early 1998 Wavelab had added Steinberg’s new VST format plug-ins alongside the existing DirectX ones, and the scene was set: slowly but surely the cross-platform VST format overtook the resolutely PC-only DirectX plug-ins in popularity, and a whole new world of creativity began to emerge from a host of software developers, alongside Steinberg themselves.
VST2 & VST 3 STANDARDS
The VST spec was upgraded to version 2.4 in 2006, adding MIDI input support so that VST softsynths could be created, the first one being Steinberg’s own Neon in Cubase VST 3.7, and for a very long time this was the standard adhered to by almost every developer. VST 3.0 was launched in 2006, supporting dynamic I/O so that plug-ins could switch from mono to stereo to surround format as required, with side-chaining as standard, and the ability to stop using your CPU when no audio was passing through a particular VST plug-in. VST 3.5 was released in 2011, adding note expression for a more natural playing feel. However, despite all the VST3 improvements, and Steinberg’s discontinuing of maintenance and finally distribution of the VST 2 Software Development Kit, many third party developers continue to develop new VST 2.4 products, largely because various other DAWs (besides Steinberg’s Cubase) still don’t support VST3 plug-ins.
Here we find ourselves in 2016, and I’m still noticing plenty of musicians who are very confused about where their VST plug-ins should get installed on their PCs, concerned that some plug-ins don’t appear within their DAWs after installation, or get their 32-bit and 64-bit versions in conflict. This is perhaps not surprising, as while Steinberg wants everyone to move over to VST3 (whose plug-ins all get installed into your C:\Program Files\Common Files\VST3 folder), with VST2 plug-ins it seems that every developer wants to install them into a different folder. Steinberg prefers C:\Program Files (x86)\Steinberg\VstPlugins and C:\Program Files\Steinberg\VstPlugins for 32-bit and 64-bit versions respectively, while other developers either use the more generic C:\Program Files (x86)\VSTPlugins and C:\Program Files\VSTPlugins, or create their own named folder in the format
C:\Program Files (x86)\‘Developer Name’\VSTPlugins and C:\Program Files\‘Developer Name’\VstPlugins.
LOCATION, LOCATION, LOCATION
The most thorough way to get all your VST2.4 plug-ins to appear within your DAW is to carefully point each install at your chosen folders; one for 32-bit versions and the other for 64-bit ones. Then the next time you run your DAW any new plug-ins found in these designated folders will be scanned and added to your existing plug-in list. Yes, it’s a bit of a fiddle if you have to point to your chosen path each time you install, but many developers remember the two locations between installs, so when you install second and subsequent plug-ins from that company your two chosen folders become the new default. If you want them on your C: partition then C:\Program Files (x86)\VSTPlugins and C:\Program Files\VSTPlugins are probably the most sensible and easily remembered locations, but it’s quite possible to locate them somewhere else. For instance, I’ve created a special V: partition on my SSD with folders named V:\vstplugins-32 and V:\vstplugins-64, so I can keep all my plug-ins together in one place that’s protected even if I have to reinstall Windows from scratch.
If your plug-ins are already scattered across multiple folders, the trick to getting all of them to appear within your DAW is to add each and every one of their folder filepaths to the appropriate section of your DAW preferences. For instance, I use Reaper, where in the Preference, Plug-ins, VST plug-in paths dialog I have “V:\vstplugins-64;V:\vstplugins-32;C:\Program Files\Common Files\VST3” so it picks up all my 64-bit VST2, 32-bit VST2 and VST3 plug-ins, across these three folders. Different DAWs will do this slightly differently, but thankfully most do allow multiple folders to be added at any time, if you find some of your plug-ins are missing after a new install. If on the other hand you want to reorganise plug-ins already scattered across a host of manufacturer default folders, you may simply be able to drag their relevant .DLL files into your desired folder (remember, one for 32-bit, and another for 64-bit ones, to avoid DAW confusion). Then change the file path location in your DAW to point to the new folders. One or two may require re-installation from scratch (particularly those with Windows Registry entries or associated sample libraries), but the majority of your plug-ins should be re-scanned and correctly recognised the next time you run your DAW(s) or WAV editors.
MULTIPLE APPLICATIONS
You may find particular applications require slightly different treatments. For instance, I have one 64-bit vstplugin folder seen by both Reaper 64-bit and Wavelab 64-bit. Reaper 64-bit uses its own internal bridge to deal with 32-bit plug-ins so I also point to another folder of older 32-bit plug-ins, used by Reaper alone. In contrast, Wavelab needs any 32-bit plug-ins to be bridged manually (I use jBridge), so for the few 32-bit plug-ins I need to use inside Wavelab 64-bit I have a separate 32-bit folder only pointed to by Wavelab. It’s a bit convoluted but works well. By the way, if anyone is wondering why some developers still insist on installing both 32-bit and 64-bit versions of their VST plug-ins, even when you only want one or the other; basically, there’s still so much confusion out there among users about the difference between 32-bit and 64-bit plug-ins and their requirements that a lot of developers make sure that both versions are always installed at one and the same time, as this can seriously reduce support calls and irate customer emails. I kid you not! Occasionally a DAW can get confused if it finds identically named 32-bit and 64-bit versions of the same plug-in, but if you’re sure you know which is the most appropriate for your setup, just delete the other .DLL file and re-scan. Good luck!
RESPONSES