Are you a plugin nerd? VST2 DLL management…

[whyterabbyt]

Would be possible, of course, however I won't do it.
You said "most of your plugins". What about these, you didn't sort into category folders? How should the script know that the parent folder of a dll file is a proper category, instead of a random install path?

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.

[TabSel]

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 ...)

[whyterabbyt]

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?

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

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?

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.

It's free, too

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.

[TabSel]

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...

[TabSel]

@ 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?

[WOK]

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?

[TabSel]

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...

[TabSel]

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...

[DevonB]

I know Devon, but I wasn't too happy to see basically what amounts to two directories in my system - the regular one and the x86 one. Then I read the FL 64 bit manual and it's even more confusing to me.
But you're correct. The plugins install where the author tells them because I do remember one 64 bit plug that wanted to install in the old path.
I don't know what the benefit is of having two directories in Win 7. I'm sure there's a valid reason, but I just don't get it.
And tell me, if we get 128 bit computers will we have 3 directories?

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

[TabSel]

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"

[seabase12]

dear TabSel,
thanks for benefiting of the pluginmanager
Yours
seabase12

[stereoCheck]

Even though this thread is ancient, I just thought I'd pipe up and say thanks, this is a great piece of software. Just upgraded my machine and this tool has massively simplified the process of getting back to where I was, and in will do the same for any future upgrades.

The only issue I've had is with Synthmaster - Live is unable to scan this plugin through the plugin managers. Has anybody seen this - do you know of any solutions?

Cheers,
Stereocheck

[Rock]

Yes, I still use it too, thanks!

[TabSel]

I‘m baffled. And happy to hear!