Jim Roseberry


Hi David,

FWIW, I like to have totally separate 32Bit and 64Bit VstPlugins folders.

C:\Program Files (x86)\VstPlugins_32Bit
C:\Program Files\VstPlugins_64Bit

This eliminates any confusion... and it allows separate control over scanning.

I started doing this a few months ago - but not soon enough. So now it's time to put the folders side by side and do some organization. :)

Really, is Http://www.familiekraft.de/PluginManager so hard to understand?


It will organise everything for you automatically...

Since X1D,or perhaps it was expanded,but X1 automatically tells me which are 32bit by placing "you guessed" it,"32bit",next to the name on the drop down menu,when using x64 X1d expanded,in Windows 7 x64.

I totally uninstalled the 32bit version of X1,BUT I find some of the "freeware" 32bit plugins very useful,as well as "Perfect Space",and the "Vintage Channel" within X1.

I have only 2 plugin folders in Explorer,c:\program files\cakewalk\vstplugins,and c:\users\documents\plugins,and have about 430 VST effects in all,and again,the 32bit ones,since the X1d update-have "32bit" next to the one's that are.
Bob

TabSel


Really, is Http://www.familiekraft.de/PluginManager so hard to understand?


It will organise everything for you automatically...

Why the pressure to use this tool? Thanks for showing it to us and I may give it a try. My preference is to manage everything from within sonar. Who knows, I may really like it.

Pressure? I've gone through the hassle of organizing dlls multiple times and spend so much time only to notice that some things won't work after manually "organizing" plugins. Some plugs won't work when you move dlls to another folder, or their update installers won't work. Some installers install x32 and x64 plugs in the same folder, some hosts won't load the right plug when there are more than one plug in the scan path. Some plugs names differ between x32/x64 build, resulting of presets save with one build not visible with the other build. Splitting x32 from x64 plugs in folders, the manual work when a x32 plug gets a x64 build later. JBridge only x32 plugs when their is no x64 equivalent. Automapping etc...

Manually organizing can lead to some frustration when things won't work as expected. I found I spent too much time "organizing" and tracking issues when things went wrong.

I think I'm not the only one and I want to just help. It works. Since I wrote this tool, there is no more work and no more issues, other than organizing plugs into categories. Not by sonars plugin layouts, instead by simply moving an .ini file into a folder, with windows explorer. It can't be easier. Sonar shows plugs as I categorized them in its browser and menus. And plugs are available equally categorized in each host I use.

No need for the jBridger tool anymore, the tool bridges what you want automatically etc. it names plugins equally for x32 and x64 hosts, etc.

Pressure? I just want to help and I can't watch people preparing to spend days "organizing" and later come up asking why this or that plug isn't found/loaded etc. instead of trying something new.

Hassle free ever since.

see: http://forum.cakewalk.com/tm.aspx?m=2658704

Jim Roseberry


Hi David,

FWIW, I like to have totally separate 32Bit and 64Bit VstPlugins folders.

C:\Program Files (x86)\VstPlugins_32Bit
C:\Program Files\VstPlugins_64Bit

This eliminates any confusion... and it allows separate control over scanning.

that works fine until you have 32 bit plugins that you need bridged to use in SONAR x64.
So I have a 3rd folder in the Program Files x86 branch labelled VST Plugins Bridged that I have SONAR x64 scan along with the 64 bit versions.
 
I might give TabSel's Plugin Manager a go as an experiement. I figure he's gone to all the trouble so why not.
I've previously paid for and used another 3rd party manager but ot got a little unweildy to use.

TabSel


Pressure? I've gone through the hassle of organizing dlls multiple times and spend so much time only to notice that some things won't work after manually "organizing" plugins. Some plugs won't work when you move dlls to another folder, or their update installers won't work. Some installers install x32 and x64 plugs in the same folder, some hosts won't load the right plug when there are more than one plug in the scan path. Some plugs names differ between x32/x64 build, resulting of presets save with one build not visible with the other build. Splitting x32 from x64 plugs in folders, the manual work when a x32 plug gets a x64 build later. JBridge only x32 plugs when their is no x64 equivalent. Automapping etc...

Manually organizing can lead to some frustration when things won't work as expected. I found I spent too much time "organizing" and tracking issues when things went wrong.

I think I'm not the only one and I want to just help. It works. Since I wrote this tool, there is no more work and no more issues, other than organizing plugs into categories. Not by sonars plugin layouts, instead by simply moving an .ini file into a folder, with windows explorer. It can't be easier. Sonar shows plugs as I categorized them in its browser and menus. And plugs are available equally categorized in each host I use.

No need for the jBridger tool anymore, the tool bridges what you want automatically etc. it names plugins equally for x32 and x64 hosts, etc.

Pressure? I just want to help and I can't watch people preparing to spend days "organizing" and later come up asking why this or that plug isn't found/loaded etc. instead of trying something new.

Hassle free ever since.

Can I edit the config ini file so that Plugins can be organised according to manufacturer?

what the tool does, basically.

A) The first time you run it:

1) It scans all your dll files recursively down the folders you specified in the VSTPluginPaths.ini

2) It creates an artificial "plugin" name from each "plugin...dll" name (it strips "(Automap)", "(x64)" etc...) to get this name. (there are usually more than one dll for a given plugin (x32, x64, automap etc...)

3) It creates a plugin.ini file and stores it in a "./cache/categories" folder.
One plugin.ini file holds each path to the various "plugin....dll"s it found, wether these dlls are x32 or x64 and some more info...

4) you CAN move these .ini files in any subfolder of "./cache/categories"

5) It creates ONE subfolder into each subfolder in "./hosts", named "categories", which replicates the folder structure in "./cache/categories" and creates plugin.dlls
The dlls created are either jBridge dlls, or "loader" dlls, whichm when loaded in a host, load the actual dll

With a "default.ini" in each "./hosts" subfolder you specifiy which dll you want the host to load.

6) You specify the "categories" subfolder in a "./hosts" subfolder as only VST Scan Path in your host

B) If you ran it again
it will only create NEW .ini files (if a new plugin is found). Already existing .ini files, no matter in which subfolder of "./cache/categories" you moved them to are only "updated", if necessary.

So, basically you categorize each plugin only once, by moving a newly created .ini file anywhere in an appropriate subfolder


You CAN specify, that you want the PluginManager to automatically create category subfolders for NEW .ini files (it's documented). The PluginManager then will create a subfolder with the same name as the parent folder of the original "plugin......dll" file...

I never used this, though. I just built this in for someone over @ KVR


It really sounds geeky, I know. But
a) it won't affect your system! If you do not understand the tool, simply delete the Pluginmanager folder... there will be no damage whatsoever
b) download the example config folder and play with the tool, to get to know how it works. Once you understand, it's pretty easy. It even creates a html documentation about all your plugins and which one will be made available in your hosts etc...

Once you understand how it works, simply sepcifiy the Plugin Scan Path in your host to the one the PM created and you're done.

(beware: Sonars Plugin Paths have a limitation of 128 chars. When the path to your plugin files get longer, Sonar won't find them. I used a symbolic link to shorten the path, I advise you to keep the path as short as possible)

SONAR doesn't care how you organize your files. When Plugin Manager scans plugins, it loads each one and queries it about its capabilities, such as whether it's mono or stereo, how many inputs it has, whether it's a time-based effect, and whether it's 32- or 64-bit. This information is then stored in the plugin inventory list in the registry.

Potential problems come when you select a plugin to insert. If there are identically-named 32- and 64-bit versions of the same plugin, you'll need some way to figure out which is which. Plugin Manager accommodates this by letting you specify the user-visible display name for each plugin, additional information also stored in the registry.