Nein, die Pfade die Du in der VSTScanPaths.ini angibst werden rekursiv nach DLLs abgeklappert, d.h. inkl. Unterordner und deren Unterordner etc…
das sollte man nicht machen lach. Das Tool ist ein Singleton, allerdings war ich bisher zu faul mir was einfallen zu lassen um zu verhindern dass es mehrfach gleichzeitig ausgeführt werden kann 
also doppelt ausführen is nicht. Das vbs-programmerl arbeitet mit den Dateien und Ordnern unterhalb ./PluginManager/…, löscht, benennt um, kopiert, erstellt Dateien und Ordner. Wenn das Programm mehrfach läuft kommen sie sich in die Quere, weil eine Instanz z.B. grad was löschen will, was ein anderes Programm gerade erzeugt, dann gibts .vbs-Fehlermeldungen. .vbs und FileSystem-Operationen sind eh tricky, da FileSystem-Operationen asynchron ausgeführt werden. D.h. das .vbs setzt z.B. nur den Löschbefehl für einen Ordner ab und arbeitet dann gleich weiter, während paralell das FileSystem u.U. ein paar Sekunden mit dem Löschen beschäftigt ist. Wenn das .vbs den gelöschten Ordner gleich wieder neu erzeugen will, führt das natürlich zu einem Fehler, weil der Ordner ja noch da ist, bis das FileSystem den Ordner komplett gelöscht hat… etc… Ich hab versucht das alles zu berücksichtigen, aber es kann schon sein, dass .vbs doch noch auf so ne “Semaphore” trifft und ne Fehlermeldung “Erlaubnis verweigert” oder so bringt und stoppt. Dann halt einfach noch mal starten. Wie gesagt, es sollte eigentlich nicht mehr auftreten, ich hab versucht das alles zu berücksichtigen…
… und schon hat man automatisch für beliebig viele Hosts ein jeweils einzlenes Plugin-Verzeichnis, mit einheitlich sortierten/kategorisierten, von automap und host-Architektur (x32/x64) unabhängig und einheitlich benamsten plugins. Dieses Verzeichnis nur noch im Host als einzigen Plugin-Pfad angeben. Fertig.
Nie mehr den jBridger bemühen und nie mehr jBridge-DLLs im System rumkopieren, nach belieben Plugins installieren, ohne Rücksicht auf x32/x64-Trennung, nie mehr DLLs im System umbenennen, kopieren oder verschieben. Nie mehr " (Automap)" im Plugin-Namen im Host etc… nie mehr mehrere Plugin-Pfade verwalten, je nach Host-Anwendung/Architektur etc…
Nein, das Tool kann nicht Automappen! Es kann nur jBridgen jBridge erstellt quasi nur Kopien seiner plugin_name.xx.dlls unter einem anderen Namen und erzeugt eine .txt-Datei gleichen Namens im gleichen Ordner wie die jBridge DLL, die den Pfad zur zu bridgenden DLL enthält. Das kann das Tool auch.
Automappen ist komplizierter, das kann das Tool nicht übernehmen, das macht man am Besten weiterhin mit der Automap Software.
Also nochmal:
- native plugins irgendwohin installieren, gegebenenfalls updaten, bei Bedarf mit Automap mappen. Keine Dlls durch die Gegend kopieren/verschieben, ist alles nicht mehr nötig.
- Auch der jBridger ist nicht mehr nötig, somit auch keine Verwaltung von jBridge-DLL-Ordnern/Dateien, darum kümmert sich das Tool.
- nach neu installierten plugins, nach updates, oder nach Automap-Updates oder wrappen/unwrappen von pluginbs mit Automap einfach das tool aufrufen, das synchronisiert dann die Änderungen für alle Hosts
Das Tool analysiert die in seinen in der VSTSCanPath.ini angegebenen Pfaden vorhandenen, nativen x32/x64-DLLs (= “x32” bzw. “x64”) und vorhanden x32/x64-automap-Dlls (= “ax32” bzw. “ax64”), und läßt jBridge-DLLs und geautomappte jBridge-DLLs unberücksichtigt.
Diese x32, ax32, x64 und ax64 - DLLs werden durch das Tool bei Bedarf gejbridged, wenn man ein “j32” (nach x32 jBridgen) bzw. “j64” (nach x64 jbridgen) davor stellt:
in der default.ini je Host gibst Du an, wie DLLs für diesen Host defaultmäßig erstellt werden sollen:
x32 = verwende Plugins nativ x32 falls die native x32 DLL vorhanden ist.
x64 = verwende Plugins nativ x64 falls die native x64 DLL vorhanden ist.
ax32 = verwende das x32 automap plugin, falls die das native x32 plugin autogemappt ist.
ax64 = verwende das x64 automap plugin, falls die das native x64 plugin autogemappt ist.
ein vorangestelltes
j32… = verwende das … und jBridge es nach x32, vorausgesetzt das … ist vorhanden und jBridge ist installiert
j64… = verwende das … und jBridge es nach x64, vorausgesetzt das … ist vorhanden und jBridge ist installiert
also z.B. “j32x32”: stelle dem Host das native x32 plugin als gejBridgtes x32 plugin zur Verfügung,
oder “j32ax64”: stelle dem Host das automappte x64 plugin als gejBridgtes x32 plugin zur Verfügung… etc…
mehere Angaben sind möglich und werden durch | voneinander getrennt, z.B.
ax64|x64|j64ax32|j64x32
diese Liste wird von links nach rechts abgearbeitet, wenn also z.B. das geautomappte x64 (=ax64) plugin vorhanden ist, dann wird dem Host ein Plugin bereitgestellt das diese ax64 DLL lädt. Wenn nicht, aber es ist das ungemappte native x64 plugin vorhanden (=x64), dann wird dem Host ein Plugin bereitgestellt das diese x64 DLL lädt. Wenn auch das native x64 plugin nicht existiert, dann wird dem Host ein Plugin bereitgestellt das die autogemappte x32 DLL (=ax32) lädt und per jBridge nach x64 bridgt (=j64ax32). Wenn auch das x32 plugin nicht autogemappt ist, dann wird dem Host ein Plugin bereitgestellt das die native x32 DLL (=x32) lädt und per jBridge nach x64 bridgt (=j64x32).
Alles klar?