Die Ordnung in Sachen PlugIns ist anscheinend OS-abhängig.
Unter OSX ist es ziemlich easy. Geht einfach unter HD/Library/Audio/Plug-Ins/VST/.
Die Steinberg-eigenen VSTs liegen unter HD/Library/Application Support/Steinberg Components/.
Allerdings nur die VST Instrumente. Innerhalb der Ordner kann frei Schnauze in Ordner summiert werden.
Die erstellten Strukturen werden anschliessend in Cubase übernommen.
Die komplette Audio FX Suite finde ich allerdings nirgends.
Und da’s ja nicht schlecht wäre alle Dyn-FX unter Dynamics usw. zu finden,
bringt mir das auch nichts wirklich. Hab schon probiert über’s Terminal die versteckten
Dateien anzeigen zu lassen. Glaube aber die sind nicht mal hidden, sondern liegen im Container der Cubase.app und
da will ich nicht drinne rumpfuschen.
Ausser die Win-Geeks sind auch Unix-Geeks und haben da einen Tipp für mich?
Ich versteh hier nämlich nur Bahnhof!
Von daher nehmt’s mir nicht übel, falls ich gerade das
Thema verfehle. Bin bloß Rainer User.
Ja, in der aktuellen zip hab ich im configs/default/hosts Ordner nicht mehr den “cubase 64bit” ordner, sondern die zwei example ordner, deren Default.ini leer ist, zum selbst ausprobieren.
Bei richtigen Angaben in der Default.ini erstellt mein Tool im example Ordner einen categories Ordner mit den gewünschten dlls. Dieser categories Ordner sollte dann als einziger Scan path im jeweiligen Host eingestellt werden.
In jedem unterordner in configs/default/hosts/ erstellt das Tool einen solchen categories unterordner configs/default/hosts//categories, der die dlls enthält, gemäß den Angaben in der Datei configs/default/hosts//default.ini
wenn man den alten
PluginManager\configs\default\hosts\c6\categories und host
erstellten dateien nicht löscht ist das skipt auch nicht sonderlich begeistert…
this window will close automaticly^^
so der moment naht, spannung.
Man muss jeden ordner einzeln angeben, falls unterordner?
ich liebe win7 (kaum zu glauben) und bin bereit fürs bett, hab jetzt alle Plugin Kategorien (nachdem ich idiot vergessen habe die vstpfade zu spechern…) eliminiert und mit einen Pfad gescannt, irgendwie fehlt da einiges im Host/c6 ordner alles was mit jbridge ist:
hab in meiner Verzweiflung sogar: ax64|x64|j64ax32|j64x32|j64x64|x32|ax32 und alle vst einen ordner gepackt…
JBridger1.5 hab natürlich die gebridten .dll`s genommen, mein windows ist vl. nicht ganz standart von den Diensten die nicht laufen, es handelt sich scheinbar um x32 plugins welche auf jx64 gebridgt worden sind welche dann geautomapt wurden, funktionierten aber beide nicht… es ist schon spät wahrscheinlich sitzt das problem vor den computer…
Für jeden unterordner in configs/default/hosts/ wird ein Scan path “categories” erstellt, dazu braucht das script in jedem dieser unterordner eine Default.ini um zu wissen welche Dlls es da reingenerieren soll.
Fehlt die Default.ini oder ist sie leer, dann meckert das Script das an, ja
Ähh, was? g erklär mir noch mal genauer bitte
Welche Ordner? Was machst Du denn? lach
Aaaaalso, das Tool jbridged selbst! (falls jbridge installiert ist)
Es scannt alle Dlls in den Ordnern die Du in der vstscanpath.ini angegeben hast (und rekursiv in den unterordnern)
Jede dll wird analysiert, ob sie ein vst2 plugin ist, welcher Architektur (x32/x64), ob die dll ein Automap Client ist (ein Automap gewrapptes Plugin) und ob die dll eine jbridge dll ist (die der jbridger erstellt)
Die jbridge dlls werden nicht weiter verwendet, da mein Tool selbst jbridge dlls erstellt bei bedarf, d.h. es ist nicht nötig den jbridger laufen zu lassen, oder ordner zu jbridge dlls anzugeben, es macht aber auch nix wenn mein Tool welche findet.
Alle dlls werden dann gruppiert, zu welchem plugin sie gehören, und für jedes Plugin wird eine .ini Datei erstellt, mit u.a. den Pfaden zu den dlls. Diese ini Dateien kannst du dann in kategorien sortieren: erstelle einfach unterordner in configs/default/cache/categories/ und verschieb die ini files in diese.
Danach baut mein Tool für jeden configs/default/hosts/ einen Scan path “categories”.
Wenn in der default.ini ein “j64x32” steht, dann erzeugt das Tool im “data” ordner für ein x32 plugin eine x64 jbridge dll, die die originale x32 dll bridged, und im “categories” ordner eine dll, die die jbridge dll im “data” ordner lädt, wenn der Host sie instantiiert… g
Das Tool kopiert dabei die “plugin_name.x32.dll” oder “plugin_name.x64.dll” aus dem jbridge installationsordner unter einem anderen Namen in den “data” folder, so wie es auch der jbridger macht.
Wenn du sagst es fehlen die jbridge dlls: bist Du sicher? Denn der Name der dll im categories Ordner ist ein anderer als Du davon jbridger gewohnt bist: der jbridger erstellt für ein nach x64 gebridgtes x32 “plugin.dll” die “Plugin.64.dll”, mein Tool aber eine Plugin.dll, der Name des Plugins soll ja immer gleich sein, ob es nun gejbridged und oder geautomapped ist…
Wenn Du sicher bist dass das jbridgen nicht funktioniert, das Tool also keine dlls für Plugins erzeugt die gejbridged werden sollen, dann findet das Tool wohl die Installation der jbridge nicht… Dann bringt auch die Angabe “j64…” nix, weil keine jbridge gefunden wird.
Vielleicht versuchst es erst mal nur mit einem bestimmten plugin, statt mit allen, und probierst mal unterschiedliche Angaben in der Default.ini und guckst, was Tool jeweils für dlls erstellt?
Jetzt ist es mir klar.
Ja ich hab die geautomapten jbridgfiles nochmal mit deinen Tool wrappen wollen…
werd es zuhause am abend testen. aber nachdem dainter eh jbridg werkt nehme ich an das die gesplitteten gejbridgden verautomapten waves auch funktionieren werden.
bei mir sind auch keine Jbridge erweiterungen nach den plugins weil das entsprechende hackerl gesetzt ist
Meines Erachtens funktionieren x32 Plugins am Besten, wenn sie zuerst geautomapped werden, und die geautomappten dann jbridged verwendet werden. Daher verwendet mein Tool entweder die nativen, oder die automappten, und jbridged dann diese falls nötig.
Ich gehe also so vor:
Plugins nativ installieren, irgendwo unterhalb eines Ordners, z.B. “c:/Plugins”
Die nativen Plugins automappen wie gewünscht (ich mappe ALLE), vst path in Automap ist allein der “c:/Plugins” Ordner.
Mein Tool laufen lassen, sobald sich durch updates/neuinstallationen oder automap-en/disabling was in “c:/plugins” getan haben sollte… Scan path ist auch allein der “c:/Plugins” ordner…
Ich hab die zip nochmal upgedated, so dass der Anwender ne Meldung bekommt, wenn für ein Plugin für einen Host keine dll gemäß Default.ini erstellt werden sollte, weil z.b. “j64x32” angegeben wurde, aber jbridge gar nicht installiert ist…
Das geht nicht!
Das Tool analysiert eine dll. Wenn es feststellt, dass es ein Automap Client ist, dann untersucht es auch die dll, die der Automap client wrapped. Wenn das wiederum eine jbridge dll ist, dann werden beide dlls nicht berücksichtigt, weil mein Tool ja selbst jbridged… Ansonsten würde ein gejbridgtes Plugins nochmal gejbridged werden… Klar?
Also, das Tool erwartet native, oder Automap gewrappte native dlls in seinem vstscanpath, gejbridgte dlls übergeht es, da es selbst jbridged, ok?
Mit den VST pfaden meinte ich die vstpaths.ini und das man alle unterordner einzeln angeben muss?
Wenn man shice gebaut hat, und man das .vbs doppelt ausführt ohne den “erstellten cach” zu löschen kam es bei mir zu (ich muss jetzt lügen), zu irgendeinen .vbs fehler, mit den skript soll was nicht stimmen oder so stand in der FM, wenn man die erstellte .dll’s im cach wieder löscht geht es…
bei den host ordner das gleiche Phenomäne mit einer anderen Fehlermeldung…
in den Host ordner einen Ordner für den besagten host erstellen und in den ordner dann eine Default.ini anlegen.
Default.ini zB:
ax64|x64|j64ax32|j64x32
reinschreiben, dass das scipt weis was es für den jeweiligen Host tun soll mit: | trennt man die einzelnen Optionen:
das .vbs Tool starten.
War gestern noch zu blöd und kann jetzt schon eine Anleitung schreiben, kann also eignltich nicht so schwer sein zu benutzen, find es sogar besser wie eine gui weil man eh keine klammern und so an schaß braucht und keine unnötigen buttons drücken muss, mann muss nur das " | " zeichen Finden (links unten/ alt gr + <) und das mit der Hosts behirnen:
x64 heisst nur x64 in den ordner rein wenn man noch ein j davor schreibt jbridgt er es mit a automapt er es auch gleich, und das zweite x sagt dann was er als Quelle nehmen soll, wobei es angeblich besser ist bei 64 bit cubase schon mal die 32Bittigen vorher-autozumappen, und dann mit TabSels Tool gleich automatisch in 64 Bit jbgridgen lassen…
Ist dieße Anleitung in Ordnung? (das Tool kann jetzt nicht Automappen? wozu kann man dann ax64x32?)
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).
die in der “.\hosts__\default.ini” stehenden Angaben gelten defaultmäßig für alle Plugins.
Wenn man aber feststellt, dass ein bestimmtes Plugin in einem bestimmten Host mit anderen als den defaultmäßigen Angaben besser läuft, dann kann man das für dieses Plugin explizit auch “übersteuern”:
Für jedes Plugin liegt ja unterhalb des Ordners ".\cache\categories" irgendwo eine .ini-Datei.
Diese .ini-Datei je plugin hat folgenden Aufbau:
Die erste Zeile in dieser .ini-Datei ist immer:
hostedBy**
(das * ist ein Trennzeichen, bitte nicht verändern!)
als gibt man entweder an: @none = plugin soll in keinem Host zur Verfügung stehen, @all = plugin soll in allen Hosts zur Verfügung stehen
oder die eben die Hosts, getrennt durch |, in denen das plugin zur Verfügung stehen soll, z.B.
Cubase 64Bit|Reaper 64Bit
wobei Cubase 64Bit und Reaper 64Bit Host-Verzeichnisse in “.\hosts.…” sind.
beim Erzeugen dieser .ini-Datei erstellt das Tool hierfür standardmäßig “@all”, man kann es aber jederzeit ändern…
als gibt man den Namen an, unter dem das Plugin defaultmäßig in jedem Host zur Verfügung stehen soll. Also unabhängig davon ob das Tool einem Host nun ein automapptes x64 plugin zur Verfügung stellt, wie z.B. “TyrellN6 (x64) (Automap).dll”, oder einem anderen Host das native x32 plugin, z.B. “TyrellN6.dll”, der Name der hier steht ist der Name, unter dem das Plugin in allen Hosts zur Verfügung stehen wird.
beim Erzeugen der .ini-Datei erstellt das Tool hierfür den Namen der nativen x32 dll. Im obigen Beispiel also “TyrellN6”. In jedem Host stünde dann also “TyrellN6” zur Verfügung, ob nun automapped, gejbridgt, x32, x64, was auch immer…
Die Zeilen danach haben folgenden Aufbau:
usageIn:
für jeden Host (jeden Unterordner in ".\cache\hosts" gibt es eine Zeile.
Hiermit kann man für einen bestimmten Host im -Feld gezielt eine expliziten DLL-Typ angeben, genauso wie in der default.ini. Wenn hier z.B. “x32” angegeben wird, dann wird dieses Plugin in diesem Host immer als native x32-DLL bereitgestellt, unabhängig davon was in der default.ini für den Host steht. Die Angabe @DefaultUsage heißt, dass die default.ini-Einstellungen gelten.
Mit kann das Plugin für einen bestimmten Host auch einen anderen Namen erhalten. @DefaultName heißt dass der in der hostedBy-Zeile angegebene Name gilt.
\
Danach folgt ne Liste mit Informationen zu DLLs die das Tool für das Plugin gefunden hat.
Normalerweise muß man in diesen .ini-Dateien gar nix machen, das Tool erstellt schon alles nötige. Man kann aber Einfluß nehmen, je Plugin, wenn man möchte.
nochmal:
das Tool analysiert DLLs in den Pfaden.
DLLs die das Tool weiterverwenden kann sind
nativ installierte
x32 plugins, z.B. “TyrellN6.dll”, und
x64 plugins, z.B. “TyprellN6 (x64).dll”
und nativ installierte, dann automappte
ax32 plugins, z.B. “TyrellN6 (Automap).dll”, und
ax64 plugins, z.B. “TyrellN6 (x64) (Automap).dll”
ok?
Das Tool kann diese vier DLL-Typen auch jBridgen. Entweder nach x32 (j32), oder nach x64 (j64).
Das Tool, kann einem Host jetzt DLLs bereitstellen.
Dabei gibst Du in der default.ini an, welche DLLs das Tool bevorzugen soll, und ob es diese jBridgen soll:
alle möglichen Angaben sind
x32 = nativ installiertes x32 plugin, z.B. “TyrellN6.dll”
x64 = nativ installiertes x64 plugin, z.B. “TyrellN6 (x64).dll”
ax32 = nativ installiertes x32 plugin, automapped, z.B. “TyrellN6 (Automap).dll”
ax64 = nativ installiertes x64 plugin, automapped, z.B. “TyrellN6 (x64) (Automap).dll”
j32x32 = nativ installiertes x32 plugin, per jBridge nach x32 gebridged, z.B. “TyrellN6.32.dll”
j32x64 = nativ installiertes x64 plugin, per jBridge nach x32 gebridged, z.B. “TyrellN6 (x64).32.dll”
j32ax32 = nativ installiertes x32 plugin, automapped, und per jBridge nach x32 gebridged, z.B. “TyrellN6 (Automap).32.dll”
j32ax64 = nativ installiertes x64 plugin, automapped, und per jBridge nach x32 gebridged, z.B. “TyrellN6 (x64) (Automap).32.dll”
j64x32 = nativ installiertes x32 plugin, per jBridge nach x64 gebridged, z.B. “TyrellN6.64.dll”
j64x64 = nativ installiertes x64 plugin, per jBridge nach x64 gebridged, z.B. “TyrellN6 (x64).64.dll”
j64ax32 = nativ installiertes x64 plugin, automapped, und per jBridge nach x64 gebridged, z.B. “TyrellN6 (Automap).64.dll”
j64ax64 = nativ installiertes x64 plugin, automapped, und per jBridge nach x64 gebridged, z.B. “TyrellN6 (x64) (Automap).64.dll”
für die zu verwendende DLL wird, wenn eine jBridge-DLL gewünscht wird, eine x32 oder x64-loader-DLL im .\data-Folder erzeugt, welche die gewünschte x32/ax32 oder x64/ax64-DLL lädt, und eine x32 oder x64-jBridge-DLL im .\categories-Folder, die die loader-DLL im .\data-Folder lädt.
wenn keine jBridge-DLL gewünscht wird, wird im .\categories-Folder eine x32 oder x64-loader-DLL erzeugt, die die jeweis gewünschte x32/ax32 oder x64/ax64-DLL lädt…
Wichtig: unabhängig davon welche DLL letztlich geladen wird, die DLL im .\categories-Folder hat immer den gleichen Namen, laut plugin.ini-Datei, z.B. “TyrellN6.dll”. Diese DLL ist auch die, die der Host letztlich scannt/instantiiert. Das Plugin steht also immer als “TyrellN6” im Host zur Vefügung, verwendet wird aber eine irgendwo installierte, eventuell automappte, und womöglich sogar gejbridgte DLL, die u.U. einen ganz anderen Namen hat…
