When I wrote a utility for sorting plugin names for the menus in Sonar, it had a 'folder name is category' setting for that very reason. I reckoned some people would have almost all of their stuff categorised themselves, so that catered for them easily.

If people have already and want to further organize their plugs, plug names, jbridge, automap manually, separately for each of their hosts, manage plug updates manually, move dlls, duplicate dlls, data folders, reg entries...

Well, then there is no need to use the tool?

As I said, it's done ONCE and for all, by drag drop, will be reflected in every host, can be changed anytime, easily.

I'd have to reconcept the tool, too, as the parent folder name of a x64 dll of a plugin could differ from the parent folder name of the x32 dll of that plugin. There could be different versions of these dlls installed in other folders, too. Which category folder shall be created?

It's too much work. It's really easy for you to drag drop a bunch of ini files into folders.
It's free, too (I stumbled upon a tool which only lets you activate/deactivate dlls with a GUI, which costs some ...)

well, yeah, if all of that is true. if only some of it is true, it still has some worth, though, surely?




Again, and Im only talking from my own experience of this, I'd make it a user option... eg use the x32 foldername, use the x64 foldername, place in an _UNRESOLVED_ category...

Just thoughts though.



Oh indeed, and its much appreciated. I'd got to the point where I was seriously considering writing scripts to do much of this very same stuff.

It actually is more than a script. I developed so called loader DLLs to be able to rename DLLs (mainly to get rid of the "automap" extension and architecture dependant name differences of one plugin, for preset compatibility; can't be done with junctions/symlinks)

If I was sure the tool is being used by more people than me, I'd support such a feature, as well as multiple configurations of the Plugin Manager, by command line options for example, though...

I just wrote it initially for myself, and it was such a pleasure to use, so that I thought I have to share with you...

I think setting up the plugin manager currently is already too much for musicians *g* even though I made it as simple as possible without a GU and spend more time documenting it than code it, already (and I won't code a GUI for it), so command line options would put even more stress to musicians...?

Don't know...

@ WOK and whyterabbyt

I hear you




I updated the Plugin Manager. It now is capable of creating categories automatically by using the first parent folder of a DLL of a new found plugin.

Thus, the Plugin Manager can adopt automatically to your organizational work you lazy people already spend hours on during installation.

(Please have a look at the documentation: Executing the Plugin Manager)

Beware: I used to install my Plugins in a folder per vendor and plugin. A "myPlugin.dll" has the Path ".../vendor/myPlugin/myPlugin.dll". When using the parent folder of a new found DLL, there would be hundreds of categories... one category for each plugin ... *g*

When you installed your plugs into ".../VST/Delay/myPlugin.dll", then using the parent folder will yield better results


So, now I did the work, now you tell me if you got it running and find it useful?

thanks! I will try as soon as I have time. The point about my request was that I have so many of the free plugins, I often forget what a plugin with a certain name is. So rearranging them would need the compare of the folders or to load every one.

One question about automapped plugins: is you plugin loader loading the plugin loader of Novation which loads the plugin or does it replace the Automap loader dll?

My plugin loader is loading the plugin wrapper of Novation which loads the plugin
(or the jBridge plugin bridger will load my plugin loader which loads the automap wrapper which loads the plugin *g*)

Concerning automap: if you did not already, then automap the native plugs you installed and leave the wrappers where they are. Or include the path to the wrappers to the VstScanPaths.ini.

Concerning jBridge: jBridge dlls and automap wrapper dlls which load a jBridge dlls will be skipped, because my tool will create a jBridge dll on demand (if jBridge is installed) and jbridging an already jBridged dll isn't necessary in short: never bother again with the jbridger and the dlls it creates. Plus: if you use a dedicated scan path per host, the jBridge settings (.jbridge files) will be host dependant, instead of plugin dependant as they are with jBridge alone without this tool. With my Plugin Manager you can have different jBridge settings for a given plugin in different hosts...
Last edited by TabSel on Tue Jun 19, 2012 11:32 am; edited 2 times in total

One more thing, repeating myself: the loader is 23kb (x32) or 28kb (x64), is no plugin, no wrapper, no bridger, will simply return the VSTMain entries return parameter of the loaded plugin to the host. There won't be any impact to stability, performance or memory usage...

It sounds weird having a plugin loader loading a wrapper which loads a plugin, or having a bridger loading a loader loading a wrapper loading a plugin *lol* but it doesn't do anything as it would do without the loader...

Well, 128 bit computing I wouldn't count on for a very long time.

Anyway, this is going to be down to how the host handle a .dll file. You want to do separate directory structures to be able to point your host of where to find your plugins. If you do a 64 bit directory structure and a 32 bit directory, you can very specifically have Cubase load plugins ONLY from that directory. So where this comes in handy is this -

You have to use both 32 and 64 bit Cubase because you have 32 bit plugins that simply do not work in 64 and you cannot give them up. So, you point the 64 bit Cubase to scan both the 32 and 64 bit directories. However, since the 64 bit plugins will NOT work on 32 bit Cubase, you make sure it does not scan the directories that have the 64 bit plugins. I also do this for jbridge stuff as well. If I got something that crashes, but I'm not sure which directory it is, I can more easily do a divide and conquer as well.

Did that answer the question? Or am I way off base?

Devon

http://www.familiekraft.de/PluginManager

Update 06/25/2012: the PM now generates a HTML documentation about the configs, hosts and plugins within the created scan paths for easy navigation. After executing, you'll find a "./PluginManager/index.html"

dear TabSel,
thanks for benefiting of the pluginmanager
Yours
seabase12