AndyB01 Posted October 3, 2020 Share Posted October 3, 2020 Hi All, hoping you can help or advise on this one. After my recent VST problem in CbB (now fixed) I did a little research into where my VST files are located and the answer - in the words of the Beatles - is here, here and everywhere. Now, there is always an argument for 'if it ain't broke don't fix it' but reality is that these VSTs are a mess and nightmare to trace and troubleshoot when things go wrong. So I'd quite like to consolidate them into a couple of folders - one for 64 bit and for 32 bit. I realise that as soon as I move them, the mapped instruments in my DAW hosts are going to break (however a clear down and re-scan of plugins should fix this). Question is, has anyone done this (successfully or otherwise), what drives/ folder structure would you recommend and are there any pitfalls I should be aware of? I am assuming a fast system SSD would be a better location than the conventional spinner HDD I use for data. Thanks in advance Andy Link to comment Share on other sites More sharing options...
scook Posted October 3, 2020 Share Posted October 3, 2020 As a rule, if a plug-in uses an installer, the best way to relocate the plug-in is uninstall and reinstall paying attention to the installer screens. Usually installers ask where the VST2 plug-ins should be installed. If the plug-in does not have an installer, it is safe to copy the plug-in and any associated files to a new folder. An alternative to actually moving files is leave them where they are and use directory junctions to logically consolidate plug-ins. For example, if I have plug-ins in c:\program files\steinberg\VST and want them to appear in c:\program files\Cakewalk\vstplugins\steinburg I would open a command shell as administrator and type mklink /j "c:\program files\Cakewalk\vstplugins\steinburg" "c:\program files\steinberg\VST" Directory junctions (mklink /j) can work across drives. There is very little advantage to putting the actual plug-ins on an SSD. The files are small and load pretty fast regardless of the drive type. Samples used by some synth plug-ins DO benefit from being on SSDs. Link to comment Share on other sites More sharing options...
AndyB01 Posted October 3, 2020 Author Share Posted October 3, 2020 1 hour ago, scook said: An alternative to actually moving files is leave them where they are and use directory junctions to logically consolidate plug-ins. For example, if I have plug-ins in c:\program files\steinberg\VST and want them to appear in c:\program files\Cakewalk\vstplugins\steinburg I would open a command shell as administrator and type mklink /j "c:\program files\Cakewalk\vstplugins\steinburg" "c:\program files\steinberg\VST" Directory junctions (mklink /j) can work across drives. Top advice thanks Scook - using symbolic links is a superb idea and will help me see everything in one place - which is what I want really. Will give that a whirl. Andy Link to comment Share on other sites More sharing options...
scook Posted October 3, 2020 Share Posted October 3, 2020 One thing I failed to mention is the effect of directory junctions on the scan path. Scan path entries should be unique. Review the scan path and remove redundant entries. In the example above based on mklink /j "c:\program files\Cakewalk\vstplugins\steinburg" "c:\program files\steinberg\VST" I would remove "c:\program files\steinberg\VST" from the scan path. 1 Link to comment Share on other sites More sharing options...
scook Posted October 3, 2020 Share Posted October 3, 2020 Best leave VST3 plug-ins in the default "C:\Program Files\Common Files\VST3" folder and DO NOT create a directory junction to it. The scanner treats the VST3 folder a little differently than other VST folders. 1 1 Link to comment Share on other sites More sharing options...
AndyB01 Posted October 4, 2020 Author Share Posted October 4, 2020 Thanks for the additional info. My main problem was a bunch of 32-bit plugins that were either missing or not supported. However I have since discovered and installed JBridge, which does the conversion and has also consolidated everything in a single folder. So a double win in that everything is now in one place and it all now works in 64 bit hosts. Link to comment Share on other sites More sharing options...
scook Posted October 4, 2020 Share Posted October 4, 2020 Retiring 32bit plug-ins should be the goal. Most plug-ins that lack a native 64bit version are unsupported and have not been maintained in years. Using these plug-ins in new projects is asking for trouble. Link to comment Share on other sites More sharing options...
AndyB01 Posted October 5, 2020 Author Share Posted October 5, 2020 Well yes I can see the argument for that but I do have a few old plugins I would be sorry to let go for which there are no 64 bit alternatives and I've not noticed too many issues as a result of using them. Perhaps when my current laptop gives up the ghost or is no longer fit for the job, I'll go for a clean set up but hopefully there's a few more years in this old laptop yet. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now