Have you ever had a VST plug-in 'go missing' when you've installed an update, or conflict with another that's been newly added to your system? PC Notes explains why it happens and offers some solutions.
Nearly every PC Musician now uses a VST-compatible host application, so there are a lot of people out there installing new VST plug-ins and instruments on a regular basis. Installing a plug-in or instrument is generally a pain-free experience: all you do is drop the appropriate DLL file into the appropriate VST plug-ins folder, and the next time you launch your sequencer the new device will be detected and added to the list of those available. Unfortunately, detection doesn't always run so smoothly, so this month I'm offering some background info on how it all works, plus suggestions on how to solve possible conflicts.
Identity Crisis
At the heart of many VST instrument/plug-in issues is the VST ID, which is Steinberg's way of uniquely identifying a particular VST instrument/plug-in. It consists of four characters, such as 'Tas4' for AAS' Tassman 4, for instance, and 'Gig4' for Tascam's GVI (Giga Virtual Instrument).
Each VST instrument and plug-in should have its own Unique ID (displayed here using Toby Bear's VST-Spy), to avoid conflicts with others in some host applications. Such conflicts can result in plug-ins or instruments 'going missing'.Since most VST plug-ins and instruments comprise a single DLL file, the VST standard incorporates safeguards to prevent a VST host application from becoming confused in the event of you installing several versions of the same product in different VST plug-ins folders scattered across your hard drives (you can examine all the IDs in your system for duplicates using Toby Bear's freeware VST-Spy utility (www.tobybear.de/p_other.html).
Hosts tend to use one of two methods when they first scan your folders for available plug-ins. Most seem to simply check for unique DLL filenames, but some also check the VST ID numbers. Steinberg maintain a web database where developers can register their unique plug-in IDs (http://service.steinberg.de/data...), but of course not every developer does this, so you may discover a few products with identical IDs. Fortunately, with many host applications that doesn't matter, and some developers even offer several versions of the same plug-in that just have different graphic interfaces and can co-exist peacefully in most host applications. ID conflicts between different plug-ins also tend to be quickly noticed by their developers, and often an update will be released a few days later to resolve an ID conflict reported by users.
Tiny Tip
If your clock automatically adjusts itself for daylight-saving changes and you have a multi-boot setup, make sure the tick-box shown here is only active in your main Windows partition.Do you have the 'Automatically adjust clock times for daylight saving changes' option enabled in Windows' Date and Time properties? If you do, and if (like me) you've also got a multi-boot PC setup, make sure you disable this setting in all but your main Internet-enabled Windows partition. Otherwise when your clock gets correctly changed in this partition, the next time you boot into a different partition it will be changed again and your PC's clock will end up an hour out.
Missing Plug-Ins
Some musicians like to keep older versions of their VST effects and synths alongside newer ones, particularly if radical changes have been made that affect CPU overheads or something about their sound. Many hosts (including Cubase SX) have no problems with you dropping several items that have identical ID numbers into your VST plug-ins folder, as long as they have different filenames, so (depending on what application you're running) you can often get different versions of the same product running happily side by side by renaming one of the files (Choirus.dll to Choirus2.dll, for instance).
However, other hosts (such as Steinberg's Cubase 4 sequencer and Plogue's Bidule modular processing/hosting software) aren't so accommodating, and if you have two products with the same VST ID, one will be ignored, even if it has a different name. This sometimes catches out commercial developers. One example is AAS' Tassman, which installs two files, named Tassman4VST_Synth.dll and Tassman4VST_Effect.dll into your VST plug-ins folder, to provide both instrument and plug-in effect versions. Both DLL files were given an identical 'Tas4' ID, and most host applications, including Cubase SX, will happily accept both files, but both Cubase 4 and Bidule will simply ignore one of them (probably whichever comes first in alphabetical order).
Cubase 4 can often be tricked into re-detecting the missing item if you move the 'missing' DLL file from the standard Steinberg / VstPlugins folder into the Steinberg / Cubase 4 / VstPlugins folder, but Bidule users can suffer major frustrations. In this particular example, some users have deleted the VST effect version of Tassman, since they only ever use the Tassman synth, leaving just one file with the Tas4 ID, which is then detected correctly.
Plogue apparently decided on the unique ID approach because they initially had far more problems scanning for unique filenames when they decided that .bidule files would be cross-platform; only by relying on unique IDs could they differentiate plug-ins across the Mac and PC platforms.
Obscure ID Issues
Sometimes a developer will inadvertently cause problems for some users while trying to help others. For instance, Tascam (www.tascamgiga.com) have been beavering away with lots of updates to their GVI (Giga Virtual Instrument). The plug-in version (but not the stand-alone one) is now compatible with Windows Vista 32, and it's possible to Import and Export all user-created presets via the Organise Presets window, for backup and sharing with other musicians. The latest version is 3.64, and running the supplied EXE file automatically installs the update over the top of the previous version.
Normally I recommend that all users upgrade to latest software versions, but on this occasion there's one very important caveat. Users of Plogue's Bidule had been having problems using GVI alongside sampled instruments that use the GVI Player software, such as Sonivox's Muse (www.sonivoxmi.com) and Wavelore (www.wavelore.com), because GVI and these various player versions had all been given the same VST ID.
Tascam's solution was to change the ID of GVI in version 3.63, which finally allows some Muse/Wavelore owners to use their sample players alongside GVI. Unfortunately, this ID change also results in Cubase 4 and Bidule (and possibly other host applications) seeing GVI 3.63 onwards as a different VST Instrument to its predecessors, so any songs created before the user updates, that already include one or more GVI instances, will display 'The plug-in "GVI" could not be found' on loading, and all the Giga instruments the user has loaded into them will have disappeared (although associated mixer channels and effect plug-ins will still appear in the mixer).
There is a partial workaround. Before you install the latest GVI update, you can load each of your songs in turn and use GVI's 'Export GSI' function to save the instrument choices and associated settings as a Giga Sound Instrument file. Then, after installing the update and getting the error message, you can load the updated version of GVI into the 'missing' VST instrument slot and then load these GSI files to restore all your instruments. Unfortunately, you'll still need to manually point the outputs of each GVI MIDI track in turn to the new GVI instrument, and re-create the now-missing mixer channels and related VST effects by hand.
Don't despair if you've already installed version 3.63 or 3.64 and lost GVI song settings. You can either re-install version 3.62 over the top of the newer update, to get all your GVI-using songs reinstated, or use the ID hack discussed in the 'ID Hacking' section in the main body of this article. I decided on the latter, replacing the newer ID of 'GVIx' with the older one, 'Gig4'. There are two immediately adjacent occurences, in reverse format, so you need to change them both from 'xIVG' to '4giG' (see screenshot at bottom of page). It worked for me!
The Developer's Dilemma
Whenever a developer releases a major new version of a soft synth or other plug-in they must make one of two choices. The first option is to keep the same DLL filename and ID as before, which means that the new product replaces (overwrites) the previous version on installation. This is normally fine and dandy, and provides the significant advantage that host applications won't see any change, so that any of your songs that required the previous version will find the new one and load the appropriate patch data into it automatically. Meanwhile, you benefit from the new features.
The second approach is to give the new version a new filename and ID, so it can (hopefully) be identified by the host application as a new product that can co-exist with previous versions already installed. A classic example of the latter approach is AAS' Lounge Lizard, which gained a completely new physically modelled 'engine' between versions 2 and 3, ending up with incompatible patch formats. As AAS changed both filename and ID, you can leave version 2 in place for your old songs that use it, and use version 3 alongside, to get the best of both worlds.
To resolve missing VST plug-in/instrument problems with some applications, you can (as a last resort) try changing the ID of a plug-in or instrument manually, using a Hex editor. Here I've just altered the two reverse ID instances inside Tascam's GVI.dll file, so that I can continue to load in all my old songs without modification.Even when the preset data remains totally compatible between two versions of a product, developers sometimes change the filename and ID. As an example, the Glitch VST real-time chopper plug-in was given a new VST ID in version 1.3.02 by popular demand from users of version 1.2.3, so that the two could be used alongside each other to audition the new features, compare new and old CPU overheads and so on. However, since the preset data was compatible between the two you could, at any time, load old presets into the new version and abandon the old one.
ID Hacking
ID conflicts should be resolved by developers, so if you discover one, drop the developer an email giving the product name, the conflicting product and the host application you're using. However, as a last resort — when a developer has gone out of business, doesn't answer emails, or is no longer updating a freeware product — you can attempt to get two products to co-exist peacefully by modifying one of their DLL files to manually change its VST ID. I must stress again that this is a last resort, and you should always save a copy of the file you're working on in case you mess things up, since incorrectly changing even a single byte of a file can render it useless and potentially crash your PC.
If you're prepared to take the risk, you can find the file's four-character VST ID courtesy of Toby Bear's VST-Spy, and once you know this you can open the DLL file you intend to change in a suitable 'Hex editor' (a programmers' utility designed to examine or modify individual bytes of any file). I recommend the excellent XVI32 from Christian Maas (www.chmaas.handshake.de), which has a tiny footprint of under 1MB, doesn't interfere with your Registry, doesn't overwhelm you with more features than you actually need, and is freeware. Open the DLL file in XVI32, do a search for every instance of this ID (in some cases its order may be reversed, so 'Plug' might appear as 'gulP'), and change each one to something different that doesn't conflict with any of your other DLL files.