VST2 Plugin Manager

Auf Deutsch
1

Ich hab mal versucht einen Plugin Manager zu schreiben.
Bei mir funktioniert er, ich übernehme keinerlei Support oder Verantwortung für Fehler etc.

Die App erzeugt für jedes Eurer Plugins neue DLLs. Es unterstützt jBridge und Automap. Auf Wunsch werden Eure x32/x64 Plugins per jBridge auf x64/x32 gebridged. Die Endung " (Automap)" wird bei automappten plugins automatisch entfernt. Die neu erzeugten DLLs sind entweder jBridge-DLLs, oder meine PluginLoader-DLLs, die nichts anderes machen, als eine plugin-DLL zu laden.

Die Applikation scannt Eure Plugin Pfade, untersucht VST2 Plugins auf Änderungen/Neuzugänge und erzeugt eine .ini-Textdatei je Plugin. Dabei wird versucht “zusammengehörige” Plugins in EINER .ini-Datei zusammenzufassen. Z.B. wird das Plugin “TyrellN6” und das Plugin “TyrellN6 (x64)” in EINER .ini-Datei “TyrellN6” zusammengefasst. Eine .ini-Datei repräsentiert/identifiziert quasi ein Plugin in unterschiedlichen Architekturen (x32/x64).

Diese .ini-Dateien könnt Ihr dann in Categories sortieren wie Ihr wollt.

In einem zweiten Schritt erzeugt die App dann aus diesen sortierten .ini-Dateien Plugin-DLL-Dateien, und zwar JE HOST.


Beispiel:

  1. Ihr teilt der Applikation mit per .ini-Datei mit, in welchen Verzeichnissen alle Eure Plugins sind.
    Datei: “…\PluginManager\configs\default\cache\VSTScanPath.ini "
    Ihr könnt mehrere Pfade angeben, je Zeile ein Pfad. In diesen Pfaden können sowohl x32 wie auch x64 plugins sein, völlig egal, die App ermittelt selbst ob ein Plugin ein x32 oder x64 plugin ist. Solltet Ihr Automap benutzen, dann einfach die Plugins mit Automap wrappen. Automap erzeugt für jedes gewrappte Plugin ein " (Automap)”-plugin im selben Verzeichnis wie das originale.

  2. Als zweites legt Ihr für jeden Host für den Ihr ein einziges Plugin-Verzeichnis mit sortierten Plugs wollt einen Ordner im Order “…\PluginManager\configs\default\hosts” an. In jedem Host-Folder erstellt Ihr eine “default.ini”-Datei, in der Ihr angebt, wie Ihr Eure Plugins für diesen Host defaultmäßig bereitstellen wollt.
    mögliche Angaben sind:
    x64 = bevorzuge native x64
    ax64 = bevorzuge automapp gewrapptes, natives x64
    x32 = bevorzuge natives x32
    ax32 = bevorzuge automapp gewrapptes, natives x32
    j64ax32 = jbridge automap gewrapptes natives x32 auf x64
    etc…
    die Angaben sind getrennt durch “|”

Die Zeile: “ax64|x64|j64ax32|j64x32”

bedeutet, das Programm soll das automap gewrappte x64 plugin verwenden. Wenn es dieses nicht gibt (weil nicht automapped z.B.), dann soll es das native x64 plugin verwenden. Wenn es dieses auch nicht gibt, dann soll es das automap gewrappte native x32 plugin verwenden und mit jBridge nach x64 bridgen. Wenn es dieses nicht gibt, dann etc…


3) Dann startet Ihr die PluginManager.vbs. Das ist ein VBScript-Programmerl.

  1. Das Ding scannt alle Plugins in den angegeben Pfaden und erstellt den Cache. Der Cache ist eine Sammlung aller .ini-Dateien für die Plugins. In diese .ini-Dateien steht z.B.
  • in welchen Hosts ein Plugin zur Verfügung stehen soll (es gibt Plugs, die arbeiten nur in bestimmten Hosts)
  • wie das Plugin im jeweiligen Host heißt, und wie es für einen bestimmten Host zur Verfügung gestellt werden soll (als x32, als x64, automapped, gejbridged etc…)
  • wo die originalen DLL-Dateien des Plugins liegen.

  1. Wenn neue Plugins in den Scan-Verzeichnissen gefunden werden (was ja beim ersten Lauf der Fall sein wird), dann erscheint ein Folder-Dialog, in dem Ihr Unterordner unter “…\PluginManager\configs\default\cache\categories” für Kategorien erstellen könnt und die .Ini-Dateien dann in die jeweilige Kategorie verschieben könnt. (Ihr könnt das auch im Windows Explorer-Fensterl machen)

  2. Sobald Ihr fertig seid, klickt “ok”, und das Programm beginnt für jeden Host-Ordner (s. oben) Unterordner gemäß Eurer Katgeorien zu erstellen und in diesen Ordnern dann die DLL-Dateien gemäß Eurer .ini-Datei-Sortierung abzulegen.

  3. Sobald der Prozess fertig ist startet Ihr Euren Host und wählt als einziges VST2-Verzeichnis das “categories”-Verzeichnis innerhalb des Host-Verzeichnisses: “…\PluginManager\configs\default\hosts<hostname>\categories”


    Wie gesagt, ich übernehme keine Garantie und auch keinen Support. Entweder funktionierts, oder nicht. Entweder Ihr kapierts, oder nicht :wink:

Entpackt das .Zip-Archiv in einen Ordner Eurer Wahl…

2

Wie gesagt, ich übernehme keine Garantie und auch keinen Support. Entweder funktionierts, oder nicht. Entweder Ihr kapierts, oder nicht > :wink:

Hmm ob ich mich nun trauen soll ? Hehe coole Idee auf jedenfall :wink:
Mal schauen ob ichs kapier :wink:

Greetz Bassbase

3

anbei die Gründe warum ich einen Plugin Manager (für mich) schrieb:

  1. Ich benutze nicht Cubase, sondern Sonar, Ableton Live, FL Studio, Reaper, Vienna Ensemble Pro, Kore2, Maschine etc., also viele verschiedene Plugin Hosts, und ich war es Leid, mehrere VST2 Plugin Paths zu managen/organisieren, für unterschiedliche Host-Architekturen (x32, x64). Jeder Hersteller kocht sein eigenes Süppchen, wo er welches Plugin hininstalliert, wie er x64/x32-Installation trennt etc…

Ich wollte Plugins installieren, und gut is. Also hab ich ein einziges Root-Verzeichnis "…\Native", unter dem ich je Hersteller und Plugin die jeweilige Installation vornehme, ob es nun ein simples dll-kopieren ist, oder ein kompletter Installer.

Ich wollte nach einer Installation keine Dateien mehr verschieben, umbenennen oder sonst wie ändern. Einfach Plugin installieren, der PluginManager soll sich um den Rest kümmern. Dateien im originalen Installations-Path / Scan-Path sollen schlicht nicht mehr angefasst werden müssen.

Meine App erstellt neue Plugins, die lediglich auf die im Installations-/Scan-Path liegenden Plugins verweisen. Der Host scannt dann die neuen Plugins, nicht mehr die im Installations-Path.


2) jBridge
jBridge funktioniert wunderbar. Es hat nur einen Haken: jBridge speichert seine Plugin-spezifischen Einstellungen in einer .jbridge-Datei im selben Ordner, wie das gebridgte Plugin. Ein Plugin das in Host A mit bestimmten Einstellungen läuft, läuft mit den gleichen Einstellungen in Host B aber nicht unbedingt. Ich brauchte also die Möglichkeit für ein Plugin in unterschiedliche Hosts auch unterschiedliche Settings zuzulassen.

Daher “erstellt” meine App JE HOST ein Root-Verzeichnis mit Plugins. Jeder Host hat “seine eigenen” Plugins und jBridge speichert seine Plugin-Einstellungen Host-abhängig

  1. unterschiedliche Namensgebung eines Plugins
    Viele Hersteller nennen Ihre x64-Plugins anders als Ihre x32-Plugins. Cakewalks “Rapture LE” z.B. heißt in der x32-Fassung “Rapture32LE” und in der x64-Fassung “Rapture64LE”. TyrellN6 heißt x32 “TyrellN6” und in der x64-Fassung “TyrellN6 (x64)”.
    Macht ja erst mal nix, aber wenn man z.B. ein einem x32 Plugin ein Preset speichert, dann “findet” man es in der x64-Fassung nicht. Die meisten Hosts speichern nämlich presets für ein Plugin in Abhängigkeit vom Plugin-Namen.

Ich wollte also dass ein Plugin, egal in welcher Architektur, immer gleich heißt.

Nun kann man Plugin-DLLs ja umbenennen. Aber manche Plugins funktionieren nicht mehr, wenn man sie umbenennt. Außerdem führt das nur wieder zu erheblichem Mehraufwand, wenn z.B. ein Update der DLL vorgenommen wird. Plugins müssen wieder umbenannt werden etc… Plötzlich hat man ein Plugin doppelt im Host, weil man’s nicht umbenannt hat, oder es wird das falsche, veraltete gescanned, weil gleiche VST-ID etc…

Ich wollte das automatisiert haben. Meine App macht das. Man vergibt nur einmal einen Namen, wenn überhaupt, und schon heißt das Plugin in jedem Host gleich, egal welche Architektur. Da dieses Plugin lediglich ein “Verweis” auf das “echte” Plugin ist, bleibt das “echte” vom Namen her unangetastet. Das “neue” Plugin kann benamst werden wie man will…

  1. Das gleiche ist auch bei Einsatz von Automap der Fall: Jedes automap gewrappte “Plugin” bekommt die Endung “Plugin (Automap)”. Presets des “Plugin” sind für “Plugin (Automap)” nicht mehr vorhanden, und andersrum. Außerdem nervt’s dass überall im Host “Automap” steht.

Umebennen kann man automap gewrappte Plugs nicht, da die DLL dann nicht mehr funktioniert.

Meine App erzeugt für Automap-Plugins eine neue DLL, die lediglich eine andere DLL lädt. Die ursprüngliche DLL bleibt also völlig unverändert, die neue DLL kann benamst werden wie man will. Instantiert man “TyrellN6” in Cubase, wird automatisch “TyrellN6 (Automap)” instantiiert.

  1. Kategorisieren

Ich bin ein Plugin-Junkie und probier so ziemlich jedes Plugin zumindest mal aus. Dadurch sammeln sich einige hundert Plugins, in unterschiedlichen Architekturen, Versionen etc. manche müssen gejbridged werden, wodurch nochmal ein paar hundert DLLs erzeugt werden. Ich benutze die meisten DLLs automap gewrapped, wodurch nochmals einige hundert DLLs dazukommen. Das alles per Hand zu managen ist mir einfach zu kompliziert. Das ganze dann auch noch schön in Ordner kategorisiert artet in so viel Organisationsaufwand bei Neuinstallationen und Updates aus, dass es fast unmöglich, geschweige denn der Zeitaufwand…

Ich wollte eine Möglichkeit ein Plugin einmal zu kategorisieren, in einen bestimmten Ordner zu stellen, und dann nicht mehr anzufassen. Höchstens später mal ne andere Kategorie wählen, wie z.B. Favoriten, einfach in dem ich nur eine einzige Datei in einen anderen Ordner verschiebe und nicht dutzende, x32/x64/gejbridgtex32/gejbridgtex64/automapx32/automapx64/automapUndGejbridgte etc…



Das macht meine App.

Sie scannt die in den ScanPaths angegebenen DLLs, ermittelt, ob sie x32 oder x64 sind, ob es überhaupt plugins sind, ob es eine Automap-Dll ist, etc. und erzeugt für so eine DLL dann einen “Identifier”. Im Prinzip ist dieser “Identifier” der Name des Plugins, allerdings ohne " (Automap), und ohne Architektur-Unterschiede im Namen (also ohne “x64”):

Aus “Vienna Ensemble Pro” wird so der Identifer “viennaensemblepro”.
Aus “Vienna Ensemble Pro x64” wird AUCH der Identifier “viennaensemblepro”
Aus “Vienna Ensemble Pro x64 (Automap)” wird ebenfalls der identifiert “viennaensemblepro”… etc…

für jeden Identifier wird dann NUR EINE EINZIGE .ini-Datei erzeugt: “viennaensemblepro.ini”
In dieser Datei stehen dann u.a. die Pfade zu allen DLLs die zu diesem Identifier gehören.

Außerdem steht in dieser Datei der Name des Plugins, wie er später im Host erscheinen soll. Dabei verwende ich defaultmäßig den Namen der nativen x32 dll. Im o.a. Beispiel also “Vienna Ensemble Pro”, egal ob es sich um die x64 version handelt, oder um eine automap gewrappte DLL, das Plugin wird im Host später IMMER “Vienna Ensemble Pro” heißen.

Man kann aber auch einen komplett anderen Namen verwenden. Z.B. “VEPro5”. Oder man kann für bestimmte Hosts einen anderen Namen vergeben, wenn man denn möchte. Wichtig ist: Das durch meine App später erzeugte Plugin, die DLL wird dann so heißen, wie in der .ini-Datei angegeben. Dieses Plugin lädt aber beim Instantiieren im Host aber dann die “richtige” DLL. Wenn also “VEPro5” in Cubase6x64 instantiiert wird, wird z.B. “Vienna Ensemble Pro x64 (Automap)” geladen.





Manchmal können Architektur-Unterschiede im Namen nicht korrekt eliminiert werden. Mir fällt jetzt grad kein Beispiel ein, ich nehm einfach mal die beiden Namen “Ex32 ample32 LS” und “Ex64 ample32 LS”. Ein und das selbe Plugin in unterschiedlichen Architekturen x32/x64. Dafür würden dann zwei .ini-Dateien erzeugt werden: “ex32amplels” und “ex64amplels”. In so einem Fall dann einfach die Pfad-Angaben aus einer der beiden .ini-Datei A an die andere .ini-Datei B anhängen und die .ini-Datei A löschen. Man muß das nur ein einziges Mal machen. Beim nächsten scannen weiß der PluginManager dann aufgrund dessen dass die Pfade in nur einer .ini-Datei stehen, welche DLLs zum Identifier, zur .ini-Datei gehört.

Manchmal ist der defaultmäßig verwendete Name eines Plugins Architekturabhängig. Z.B. wird bei Rapture32LE und Rapture64LE, der x32-Name verwendet, also Rapture32LE. In einem x64-Host würde also das Rapture32LE plugin zur Verfügung stehen, obwohl das Rapture64LE geladen wird. In diesem Fall einfach den Namen des Plugins in der .ini-Datei ein einziges mal ändern auf “Rapture LE”, und schon heißt das Plugin, egal in welchem Host, egal in welcher Architektur “Rapture LE”.



Die Identifier- .ini-Dateien können nach belieben in Unterordner sortiert werden. Das ganze macht man einmal und muss es dann nie wieder machen.




Jedesmal wenn ich nun ein Update eines Plugins mache, oder ein neues Plugin installiere starte ich lediglich meine “PluginManager.vbs”. Diese scannt dann den Installationspfad nach Neuzugängen und Änderungen und gleicht diese mit den vorhandenen .ini-Dateien ab. Sollte eine neue .ini-Datei hinzukommen erscheint ein Dialog in der man die neue .ini-Datei in einen Kategorie-Unterordner verschiebt.

Danach erstellt die App die Plugin-Pfade und Unterordner für jeden Host neu, gemäß der Kategorisierung der .ini-Dateien.


Also: Nur noch neue Plugins installieren, Updates machen, die Installationen sonst nie mehr anrühren, außer vielleicht die Plugins bei Bedarf mit Automap wrappen. Dann den PluginManager starten und schon steht das Plugin mit einheitlichem Namen für Presets und mit je host individuell möglichen jBridge-Einstellungen wie gewünscht sortiert in den Hosts zur Verfügung.

4

HI
Respekt vor so viel èberblick :wink:
Krass krass wird einem ja schwindlig beim lesen :wink: da hat sich wer was bei gedacht ^^ Pluginjunkies.
Ich blicks mit programmieren gar nicht drum hab ich halt ein dualboot ein saubere DAWumgebung mit dem was ich auch brauch und nutz und ein windows für Office Spiele und ein zugemülltes Cubase das bei Bedarf einfach komplett gelöscht werden kann ohne das ich dann mir dann ein Kopf machen muss das ich nun erst wiedr alles installieren muss falls die Muse mich überkommt :wink: einfach Sysemwechsel und gut ist. Cubase selbst is ja ohne das ich komplett komplete 7 instalier recht schnell wieder drauf und weiter kanns gehn mit ausprobieren. Die guten aufs Backupplätchen die schlechten in den Mülleimer :wink:,

Greetz Bassbase

5

Hi TabSel!
:slight_smile:
Kann es sein, dass du früher oft im Cubase-Forum warst?
Hammergeil, was du da umgesetzt hast - gefällt mir. Dickes Kompliment!
:sunglasses:
Dennoch finde ich das alles doch arg aufwändig, und somit ggf. etwas fehleranfällig (?) (wenn ich das richtig einschätze?)
Bei mir gilt es z.B. einen alten Testrechner, da kommen erstmal alle .dll´s, Freewareteile, Plugins, Update-Checks rauf.
Und es kommen dann wiederum später nur die besten davon auf meinem Haupt-Audiorechner im Studio, mit denen ich dann auch täglich schnell und stabil arbeiten kann.
Nun, ich will nämlich keine ellenlangen durchzuscrollenden Listen von abertausenden EQs, HallFX, Delays und Kompressoren oder Synths. Auch wenn die dann irgendwie frei geordnet werden können.
Nur wenige richtig gute Plugins davon reichen mir, die ich dann aber auch sehr gut kenne und somit schnell zum Ziel komme. Zumal ich denke, dass heutzutage schon die internen DAW-Plugins (Cubase) sehr gut für die tägliche anfallende Arbeit sind und man nicht zwingend Dritthersteller braucht. Aber egal, darum geht es ja nicht.

Frage an deine App:

  • Wenn ich Songs in ein anderes Studio mitnehme, oder auf dem Laptop im Übungsraum, funktioniert das dann auch noch?
  • Gibt es ggf. Probleme bei älteren XP-Systemen?
  • und wie schaut´s aus, wenn ich meine Cubase-.cpr´s auf dem Mac öffne, dort ja andere System-Hierarchie gegeben ist?

Richtig rumfummeln im System mag ich ansonsten lieber nicht, das muss ich zugeben. Und damit habe ich über viele Jahre nun mal sehr gute Erfahrungen gemacht. Zumal ich damit auch meine Kohle verdiene, und das System muss einfach Hammer rund und verdammt stabil laufen. (tut es ja auch!) :mrgreen:
So hab ich grad nicht so das Bedürfnis, etwas im System ändern zu wollen… Die Zeit hab ich auch gar nicht.

Ich las Reaper bei dir. Das ist auch so ein typischer Fall einer sehr leistungsfähigen Software, die man recht zeitaufwändig konfigurieren kann, und oft sogar muss, um seine Arbeitsweisen oder gar die GUI-Ansicht (kann man ja alles wunderbar dort anpassen) entgegen zu kommen.
Aber auf das alles hab ich echt keinen Bock drauf - ich will sofort loslegen, und alles ist schick und stabil und immer an dem Platz in der DAW, wo es auch hingehört. Und dies dann auch in anderen Studios, z.B. beim Projektaustausch (!). Daher nutze ich auch primär sehr erfolgreich Cubase/Nuendo.


Gruss
Cent.

6

geschrieben hab ich das vbscripterl auf Win7. Die tools-DLLs zum Laden einer DLL sind auch auf Win7 kompiliert. Ob das auf XP läuft weiß ich nicht :wink:

Aufwändig finde ICH es mit meinem PluginManager gerade JETZT nicht mehr. Ich installier einfach nur noch Plugins und Updates unterhalb des Root-Verzeichnisses meiner Plugins und fass da nie mehr was an. Der Manager macht den Rest und erzeugt mir einen schönen Root-Folder für alle Plugins je Host, so wie es der Host bzw. das Plugin gerade braucht, schön sortiert.

Geschmackssache. Niemand muß ja seine Arbeits- und Organisationsweise umstellen. Für MICH passt das so super. Endlich verbringe ich keine Zeit mehr Plugins/Updates/jBridge/Automap zu managen!

Nur ein Beispiel: Letztens kam Automap 4.3 raus. Ich hab alle meine Plugins gewrapped, wie in den ReleaseNotes angegeben und hab Sonar gestartet, nur um festzustellen, dass Automap 4.3 nen Bug hat, der in Sonar dazu führt, dass Sonar abschmiert, sobald man ein automapptes Plugin zweimal instantiiert. Ich stand also vor der Wahl, Automap 4.3 zu deinstallieren (blöd, weil es einige Bugs in allen anderen Hosts beseitigte), oder meine Plugins OHNE Automap zu nutzen (in keinem einzigen Host). Stattdessen hab ich in meinem Manager Sonar so konfiguriert dass es alle Plugins mit der jBridge lädt. Dadurch schmierte mir Sonar nicht mehr ab. Ich hab EINE ZEILE geändert, den Manger laufen lassen und konnte weiter machen.

Wie gesagt, ich hab viele viele Plugins, viele viele Hosts, jBridge und Automap, in nem x64 OS mit x32 und x64 hosts und hätte alle Plugs in jedem Host gerne einheitlich benamst und einheitlich kategorisiert. Das alles manage ich jetzt mit ein paar Zeilen in .ini-Dateien, statt multiple Folders per Hand zu managen, per jBridger bridgen, automappen…

Aufwändig ist’s, weil kein GUI existiert, man stattdessen in .ini-Dateien rumfriemeln muss, damit der Manager das gewünschte macht. Aber ich hab das halt geschrieben, weiß wo ich hingucken muss und wo ich was angeben kann und muss. Wenn’s für jemanden anderen taugt, bitte gerne, wenn nicht, dann halt nicht :wink:


Frage an deine App:

  • Wenn ich Songs in ein anderes Studio mitnehme, oder auf dem Laptop im Übungsraum, funktioniert das dann auch noch?
  • Gibt es ggf. Probleme bei älteren XP-Systemen?
  • und wie schaut´s aus, wenn ich meine Cubase-.cpr´s auf dem Mac öffne, dort ja andere System-Hierarchie gegeben ist?

Jeder Host identifiziert Plugins anhand deren VST-ID. Ein Host scannt Plugins, um zu wissen, welche DLL er laden muss, wenn ein Plugin mit der ID xyz geladen werden soll. Egal wie das Plugin heißt, solange die ID die gleiche ist kann jeder Host, unabhängig von der Maschine auf dem er läuft die richtige DLL laden, wenn er sie gescannt hat.
Songs sind also grundsätzlich so lange kompatibel, solange irgendeine Plugin-DLL mit der selben ID geladen werden kann, wie sie auch gespeichert wurde, unabhängig vom Namen.
Beispiel: Wenn ich in Cubase x64 nen Song erstelle und das Plugin “TyrellN6 (x64) (Automap).dll” (ID1234) verwendet habe, und dann im Automap den TyrellN6 x32 und x64 unwrappe, dann gibts die “TyrellN6 (x64) (Automap).dll” ja nicht mehr. Außerdem lade ich den Song in Cubase x32. Cubase x32 hat u.U. eine DLL "“TyrellN6.dll” gescannt und diesem die ID 1234 gegeben. Beim Laden des Songs wird die DLL geladen, die der ID 1234 entspricht, das wäre in Cubase x32 dann also die “TyrellN6.dll”…

In Kurz: Ja, Songs sind untereinander austauschbar, keinerlei Kompatibilitätsprobleme.
Die Plugins müssen schlicht einfach nur “vorhanden” sein und die Scan-Liste (ID<>DLL) des Hosts sollte halt aktuell sein.

Die IDs sind auch völlig unabhängig vom OS (XP/Win7), Plugins sind also auch OS-Unabhängig. Es kann nur sein, dass der PluginManager auf XP nicht funktioniert, das weiß ich nicht…

7

schnell mal…(muss hier gleich weiter machen)
sag, gibt es in Sonar nicht sowieso einen Plugin-Manager? meine mich daran erinnern zu können?
zur Verständnis: also jede .dll hat ihre eigene ID, anhand die Host-DAW das richtige Plugin zuweist?
es wäre dann egal, ob man das einfach umbenennt? wie gehen DAWs damit um bei Songstart? scannen die nicht eher doch die Namen? (hatte das mal ausprobiert, umbenennen klappt nicht, glaub ich…?)
Auch Beispiel Kontakt: gibt ja etliche Versionen schon dafür, argh. Was, wenn man ältere Song öffnet, und das damalige Kontakt-Plugin nicht mehr installiert hat? einfach umbenennen geht ja nicht, oder? wie löst das Reaper, da las ich doch was letztens zu?

Gruss
C.

8

ja, gibt es. Der hat allerdings so seine Tücken, um die man erstmal “herum” arbeiten muss, das GUI dafür ist wenig benutzerfreundlich, die Orga-Arbeit dauert daher schon ziemlich. Und dann hat man’s auch nur in Sonar organisiert, nicht aber in anderen Hosts…

Wenn ich einen bestimmten EQ will, dann will aber nicht in jedem Host und dessen Plugin-Architektur stöbern müssen, ich will das Ding LADEN! :wink:

Was so ziemlich jeder Host macht ist, VST2 plugins gemäß der Ordner-Hierarchie darstellen in der sie liegen. Cubase macht das (in seinen Plugin-Menüs), Sonar macht das (in seinem Browser und in seinen Menüs), Reaper macht das, Live macht das, VEPro5 macht das etc… Kore2 macht das nicht (von Haus aus, man kann aber schön selbst organisieren und in der DB suchen), Maschine hat leider nur eine lange Scroll-Liste und keine andere Möglichkeit was zu organisieren, und FL Studio hat auch nur ne Scroll-Liste, aber auch den netten PluginPicker…

Nun will ich wirklich nicht in jedem Host kategorisieren, das wäre redundante Fieselei und DAS ist Fehleranfällig. Sortier ich in einem Host was um, muß ich das in allen anderen auch machen. Der kleinste gemeinsame Nenner hier ist einfach die Ordner-Struktur in der die VST2 Plugins liegen. Den mach ich mir zu Nutze: Einmal auf übergreifender OS-Ebene die .ini-Dateien in Kategorien-Verzeichnisse verschoben und den Manager laufen lassen.
Die Hosts scannen automatisch neu und stellen die Plugins automatisch sortiert dar. Überall die gleich Kategorien-/Ordner-Struktur, überall der gleiche Name…


Nö, jedes “PLUGIN” hat seine eigene ID. Für ein PLUGIN kann es mehrere DLLs geben. Eine x32-Plattform-Dll und eine x64-Plattform-Dll z.B. “TyrellN6” und “TyrellN6 (x64)” haben die GLEICHE ID! Der Host scannt DLLs und ermittelt zur DLL die ID. Jeder host handelt das auftreten mehrerer DLLs mit gleicher ID anders. Cubase z.B. ignoriert DLLs deren ID bereits durch eine DLL zuvor gescanned/ermittelt wurde… Wenn Du “TyrellN6.dll” UND “TyrellN6 (x64)” im selben Scan-Path hast und Cubase scannt, dann verwendet Cubase die erste dll die es für eine ID findet. Was die erste DLL ist bestimmt die Reihenfolge in der Cubase durch die Ordner liest bzw. auch seine Prioritäten, z.B. kann es sein dass Cubase x64 zuerst native x64 dlls scannt, danach erst die x32 DLLs die die VSTBridge laden könnte. In jedem Fall hast Du immer nur EINEN TYRELLN6 in Cubase zur Verfügung. (Wobei es auch hier wieder zu differenzieren gilt, denn Cubase hat einen Identifikations-Bug, der dazu führt dass DLLs mit einem DLL-Namen der weniger als 9 Stellen hat anders identifziert als das selbe Plugin mit gleicher ID nur mehr als 9 Stellen im Namen, deswegen sieht man z.B. “Embracer” UND “Embracer (Automap)” BEIDE in Cubases Plugin Menü… :wink: )


Wenn Du einen Song in Cubase x64 mit “TyrellN6 (x64).dll” machst, dann kannst Du den Song auch in Cubase x32 laden, solange Cubase x32 die “TyrellN6.dll” gescannt hat.

Prinzipiell ja, was das Identifizieren/Zuordnen einer DLL zu einer VST-ID durch den Host betrifft. Ein Host speichert in seinem Song NICHT den Namen der DLL, sondern die ID des Plugins.

Anders sieht es aber mit z.B. Presets aus: Cubase speichert VST3presets für Plugins in einem Ordner, der den Namen der Plugin-Dll trägt. Daher findest Du “Embracer”-presets z.B. nicht, wenn Du “Embracer (Automap)” benutzt, weil Cubase in nem anderen Ordner sucht und nix findet. Wenn Du mit “Embracer (Automap)” ein Preset speicherst, findest es mit “Embracer” nicht mehr… etc… Gleiches gilt für Reaper etc… Wenn Du in Cubase x64 ein VST3preset für “TyrellN6 (x64)” speicherst, findest es in Cubase x32 nicht, weil Cubase die “TyrellN6.dll” instantiiert und im Ordner “TyrellN6” nach presets sucht… etc…
D.h. obwohl das Plugin das gleiche ist, und auch die Preset-Daten, so identifizieren Hosts presets meist NICHT anhand der ID, sondern anhand des DLL-Namens. Ich finde das ziemlich blöd und inkonsequent, ist aber halt mal so.

Was Presets betrifft also auch hier wieder der kleinste gemeinsame Nenner, und das ist der DLL-Name. Nenne Plugins in jedem Host, in jeder Architektur gleich, dann findet man sie schneller und Presets sind zwischen Architekturen austauschbar.

“Gleich nennen” ist aber durch simples umbenennen der DLLs nicht getan. So manches Plugin nutzt den Namen oder auch Speicherort seiner DLL. Steinbergs Embracer z.B. funktioniert nur, wenn die DLL im VSTPlugins-Unterordner im Cubase-Verzeichnis liegt. Automap gewrappte DLLs funktionieren nur, wenn sie die Endung " (Automap)" haben etc…

Mein Manager verwendet daher “Tool-DLLs”, die, wenn sie geladen werden, eine andere DLL laden. Daher kann meine TOOL-DLL z.B. “A.dll” heißen, und sobald sie z.B. durch den Scan-Vorgang geladen wird, einfach “Vienna Ensemble Pro x64 (Automap)” lädt und gegenüber dem Host einfach “so tut”, als hätte Cubase eben diese DLL geladen, statt der “A.dll”…

unterschiedlich :wink: Wie gesagt, “üblicherweise” identifizieren Hosts Plugins anhand der ID, die sie beim Scannen für eine DLL ermittelt haben, unabhäbgig vom Namen. Dann gibts noch so Sondersachen g Um die ID eines Plugins zu erhalten muss ein Host das Plugin instantiieren, also die DLL laden, das Plugin initalisieren etc… das DAUERT!
FL Studio z.B. kann “schnell scannen”, wie auch Reaper. Dabei laden sie die DLL nicht - bzw. durchlaufen dann nicht den kompletten Plugin-Initialisierungsprozess, sondern scannen einfach nur die DLLs in den Ordnern und bieten dann die Datei-Namen (ohne .dll) in Ihren Plugin-Menus an. Dennoch: Spätestens wenn ein Plugin in einem Song instantiiert wird, weiß der Host die ID und speichert die ID im Song, NICHT den Namen.

Kontakts Versionen haben alle eine separate ID. “Kontakt 2” hat eine andere ID als “Kontakt 3” etc. Wenn Du einen Song erstellt hast mit “Kontakt 2”, “Kontakt 2” dann deinstallierst, dann kannste den Song auch nicht mehr vollständig laden, weil kein Plugin mit der ID des “Kontakt 2” gescannt sein kann…

Umbenennen klappt da eben nicht, weil ein Plugin durch seine ID identifziert wird, NICHT durch den Namen.

Reaper ist da speziell, der kann alles lach aber auch bei Reaper gilt: Identifikation eines Plugins PRIMÄR über die ID. ReaMOTE dagegen stützt sich auf den DLL-namen (und Pfad!)…

Ist eben alles ein bisschen komplizierter. Und daher auch mein Manager, der übernimmt mir all das Denken und organisieren, nimmt den kleinsten gemeinsamen Nenner aller Hosts, nämlich den DLL-Namen und die Ordnerstruktur die der Host scannt und bridged auch noch bei Bedarf und wählt die Automap-DLL falls gewünscht, statt der originalen…

9

Alter Latz Hut ab TabSel

So langsam versteh ich ein paar Zusammenhänge, danke für die schönen Erklärungen :wink:

Greetz Bassbase

10

oha, sehr geile tiefgründige Kenner-Infos, Hammer TabSel! :smiley:
bin etwas im Stress, ich les später genauer rein, sehr sehr interessant!!
:sunglasses:
trotzdem auf die Schnelle: wie ist das mit den neuen VST3-Plugins? die haben ja eine andere Architektur, kann man die nicht auch frei “Plugin-pfaden”? oder geht das da doch nicht?

11

VST3s werden nach Kategorien sortiert angezeigt, die das VST3-Plugin selbst vergibt.
Die Katgeorie bestimmt sich bei VST3 plugins ausschließlich durch die “Tags” des VST3-Plugins, NICHT der Speicherort/Ordnerstruktur der .vst3 (dll).

Daher ist meine App ein VST2 Plugin Manager. An VST3 Plugins kann man nur entweder die Tags in nem Hex-Editor hacken, oder darauf bauen, dass Steinberg einen Plugin Manager realisiert (der dann hoffentlich die Ordner-Struktur von VST2-Plugins und die Tags von VST3 plugs gemeinsam berücksichtigt)

12

Hi

Also ich bin dafür das Steinberg TabSel anheuert und wir so allen in den Genuss eines durchdachten Pluginmanagers kommen :wink:
Vorrausgesetzt TabSel würde das auch wollen :wink:


Greetz Bassbase

13

dacht ich mir schon. Das ist der Nachteil mit den VST3´s.
Was soll´s. (VST3 finde ich ansonsten nur Hammer!!)
Ich tröste mich damit: bei ProTools und Logic läßt sich überhaupt nichts frei vom User definieren, wenn es um Plugin-Reihenfolge/Pfade geht :mrgreen:
Wobei Steinberg doch echt einen PluginManager bauen könnte. Das ginge sicherlich. Sofort mit rauf auf die Wunschliste!!! :sunglasses:

Echt im Stress grad:
Cent!

14

Echt im Stress grad:
Cent!

:laughing: dann musste Prioritäten setzen :wink: erst die Arbeit dann das Vergnügen :wink:

Greetz Bassbase

15

mach mich nich wahnsinnig hier, Herr Kollege!!! :laughing:
parallel Steuermist und Office offen… nützt ja nix.
Das hier ist aber viel interessanter… Kann man nix machen… das hat man nun mal drin tief im Herzen. :mrgreen:
uff.

16

Jo, cubase als vbscript!!! g

Das kann Steinberg ganz sicher besser g

Mein Plugin Manager ist ja nur ein File Manager auf OS-Ebene, der mit Dlls, auch aus jbridge und Automap arbeitet. Damit wird sich Steinberg zu Recht nicht abgeben wollen.

Das Managen/Sortieren/Kategorisieren/Taggen/MediaBay-Integration etc. von Plugs INNERHALB Cubase ist, worum sich Steinberg kümmern sollte!

17

ähm…TabSel…
oben stand ja, dass du das gute alte Cub´se gar nicht mehr nutzt? wasn das für ne Aussage? erklär uns das mal bitte…? :mrgreen:

18

Da fehlt ein “nur”…

Ich benutze nicht NUR Cubase…

19

Ein Polysequenzeromane also :wink: ich hab mit Cubase schon mehr als genug (zu lernen / tüfteln),
aber manche brauchen halt mehr…

@will dich doch ned wahnsinnig machen hab ich doch nix von :wink:

Greetz Bassbase

20

Sehr schöne Idee!

Ich muss mal sehen ob ich mich das an meiner 2.DAW traue, die muss ich sowieso bald auf Win 7 neu aufsetzen.