VSTs Via Symbolic Links

[aspsa]

I read threads here and elsewhere on creating symbolic links to provide a better user experience with respect to organizing VST folders for view within Ableton Live's plug-ins folder (or, for that matter, any host that exposes VSTs and other plug-in formats). As you may know, creating VST subfolders in OS X as a means to organize one's VST plug-ins at times produces unpredictable results. For example, after I upgraded to Arturia's 'V Collection 5' suite, I opted to create an 'Arturia V Collection 5' VST subfolder under the standard VST path in OS X Yosemite. Strangely, when I ran Live 9.7.1 only 'Analog Lab 2' and 'Spark' appeared in that subfolder. The only way I was able to access all the plug-ins in that suite was to relocate them directly under the VST folder.

Next, I considered using OS X alias files. Here is an example of what I did.

• Created a 'VST Source' folder at the same folder level where the 'VST' folder exists, making 'VST Source' a 'VST' sibling folder
• Copied the '../VST/Arturia V Collection 5' folder's content (i.e., only the files in that folder) to the 'VST Source' folder
• Back in the 'VST' folder I added the following subfolder structure: '/By Brand and Product/Arturia - V Collection 5'
• From the '.../VST Source' folder I Option+Command dragged all the plug-ins into the '/By Brand...' folder (i.e., I created aliases of the source files)

When I ran Ableton Live, the '/By Brand...' subfolder structure appeared under 'Plug-ins -> VST' in the browser panel. I was able to select any of the plug-ins for use within an Ableton track.

For the sake of preserving a human-readable ordering of plug-ins, I enhanced my approach a bit. Simply, I followed the preceding steps, except this time I place the 'Arturia V Collection 5' plug-ins in a '.../VST Source/Arturia V Collection 5' folder. As before, I created aliases by Option+Command dragging the plug-ins into the '.../By Brand...' folder. When I restarted Ableton Live 9.7.1, 'Plug-ins -> VST' in the browser panel faithfully displayed the aliased files under 'By Brand and Product'. However, I was unable to drag any of the plug-ins onto an Ableton Track.

Having read the symbolic link threads, I modified my attempt at preserving a human-readable ordering of plug-ins while allowing me to create any number of plug-in views by categories that I prescribed. So, I instead of Option+Command dragging the plug-ins, I opened the Terminal application and created symbolic links to the plug-ins. Rather than aliases, the '.../VST/By Brand...' folder now contained symbolic links. I tested this once again in Ableton Live 9.7.1, and it worked.

This approach has the following advantages:

• Declutters your VST folder. One may wish to clear his VST folder for performance reasons. At the very least, a less populated VST folder allows Ableton Live (and, I imagine, any VST host) to improve its start-up time. Also, I suppose fewer computing resources are required. In my case, I prefer to have all my VSTs available at all times, accepting convenience over (hopefully) small CPU and memory hits.
• Allows one to create multiple 'views' of the same source plug-ins. In the preceding example, I opted to have a 'By Brand and Product' view of my source plug-ins. In this view and in this example, all the Arturia V Collection 5 plug-ins were available through symbolic links to them. Although I did not try this yet, I see no reason why I should not be able to create other 'views' that contain a subset of symbolic links. For example, additionally I may prefer to have this view: 'VST/Synths'. Under this view I may decide to add symbolic links only for 'ARP 2600 V3.vst', 'CS-80 V3.vst', 'Jup-8 V3.vst', etc. Here is another possible view: 'VST/Physically Modeled'. In this folder I would add all the Arturia V Collection 5 plug-ins less 'Analog Lab 2.vst' and 'Spark.vst'. As I organize all my plug-ins, I would add u-he's 'Diva.vst' to this view among other plug-ins.

From an organizational perspective, having multiple 'views' let's me find relevant stuff more quickly, and using symbolic links helps me do this efficiently.

Possible disadvantages:

• Plug-in maintenance. As I have only just now taken this approach, this possible disadvantage may manifest itself as I incrementally update my plug-ins. Unless a plug-in's installer package allows one to select a specific folder under which to install the plug-in, then I will have to do some 'clean-up' work after installing the incremental updates.
• Incremental updates fail. If a plug-in's installer package expects earlier versions to exist in the default plug-in locations, then I may need to drag copies for these versions into the standard locations before updating them.
• In all cases, one needs to ensure the proper symbolic links are created in the views, such that each symbolic link associates with the specific plug-in version desired. However, aside from that, I see no reason why I cannot simply copy existing symbolic links across multiple views. For example, I should be able copy and paste a 'B-3 V.vst' symbolic link from the '.../VST/By Brand...' folder to the '...VST/Physically Modeled' folder. After all, the symbolic link is simply a pointer back to the source file, and, therefore, a copy of that symbolic link also points to the same source file.

Has anyone else taken this approach? Before I commit re-organizing all my VST and AU plug-ins, I respectfully ask for your thoughts on this matter and for your collective experience in taking this approach or one similar to it.

[Stromkraft]

I used to organize VSTs into folders myself. All I've done is making a Live rack preset of each plug-in and as I put these in my User Library I can make copies into different folders there and I can load from there, also with Push these days.

This way I can have any organisation I want and leave the VST folder alone. The problem with moving things around there manually is that update processes may not be able to find the old plug-ins and will leave them in their folder while the root is updated, breaking havoc when you want to load the latest. In addition it's a bad idea to changes there because if you get into a crashing streak how will you know this is not because something you did?

Live rack presets are very quick to make and saves me from stuff like having to deal with aliases or soft links (You can't use hard links to folders and plug-ins are folders).

[aspsa]

The problem with moving things around there manually is that update processes may not be able to find the old plug-ins and will leave them in their folder while the root is updated, breaking havoc when you want to load the latest. In addition it's a bad idea to changes there because if you get into a crashing streak how will you know this is not because something you did?

Yes, good points. This is why I was hesitant to commit to the custom VST folder approach, especially in light of potential maintenance challenges. Your recommendation, which I have suggested by a number of other people, is a good compromise.

Pros:

• Retains standard AU and VST folder constructs, which supports successful standardized plug-in installs, updates and upgrades.
• Working within the Ableton browser context (e.g., the User Library) Live Racks can be built and copied across multiple 'views' as described in this thread.
• While I have not tried this yet, I suppose a Live Rack can be used to store specific configurations and/or preset selections. For example, I may create an Instrument Rack with a Kontakt plug-in and pull up some piano library or some piano .nki, where a library file is unavailable. With this configuration I could then store the Instrument Rack as 'Piano...' and place it under a Piano view in the User Library. Similarly, I can copy that Instrument Rack to another view in the User Library, say 'Traditional Keyboard Emulations'. Likewise, I could pull up a Kontakt instrument, load a drum library, configure the Kontakt outputs, apply FX to the Kontakt mixer's channel inserts and aux sends, adjust the Kontakt mixer levels, etc., and save the Instrument Rack as 'Drum Kit...'. I think these settings are preserved as part of the Instrument Rack, right? Otherwise, would preserving these settings require saving, for example, a new .nki file or saving the Ableton Track with this Instrument Rack as a Live clip?

Cons:

• A similar approach would need to be developed and applied for different DAWs; this is a significant amount of rework depending upon how many plug-ins are involved. However, the up side is that the custom VST folder approaching, assuming it does not impact loading AU and VST plug-ins into a host, would centralize the prescribed views in a manner that is abstracted away from the DAW. The DAW would simply need to point to the custom folders and on the Mac OS symbolic links would redirect to the source plug-ins.