VST2 Plugin Manager

cool Danke TabSel!!!

wave plugin in wave shell > shell 2 vst > jbridge > automap > TabSels VST2 Plugin Manager > cubase.

Das wär doch mal was^^

Schon ausprobiert?

Mein Manager macht ja “nix” mit Plugins, ist keine Bridge, sondern “nur” ein File Management Utility, also wenn wave plugin in wave shell > shell 2 vst > jbridge > automap eh funktioniert, funktioniert auch mein Manager, der würde nur den JBridger ersetzen… Der Manager ist quasi ein enhanced jBridger (wenn jBridge installiert ist)

Nein, leider nicht…

Kannst du uns kurz verraten wie du das gemacht hast, also in 10 Sätzen o. so?

gLG

Was meinst Du?
Hab halt nachgedacht mit was ich zuviel Zeit wiederkehrend unnütz verbring und wollt mir dann ein Programmerl schreiben, dass das soweit möglich automatisch macht. Dann hab ich viel rumprobiert mit vbscript, a bisserl C/++, Visual Studio Express downgeloaded und für x64 getweaked, mit DLL-/Vst-Architektur gespielt, analysiert wie jBridge und Automap wrapping funktioniert und was ich da automatisieren kann, analysiert wie hosts Plugins scannen/laden, Presets speichern, es mit symbolischen links versucht, alles über den Haufen geschmissen, drauf geschissen, anders probiert :wink:

Bis es funktionierte.

Dann wollt ich ein GUI in html entwickeln und hab mich dann doch für anderes, schöneres entschieden, immerhin funktioniert das Script ja schon :wink:

Moment! TabSel, das waren keine 10 Sätze!
:laughing:
Darf ich als Nicht-Kenner der Programmierer-Szene etwas dazu sagen?
krank. sowas von krank. aber echt.
:mrgreen:
nein, echt Hammer, was du da angestellt hast!!
Denke, einen kleinen Obolus hast du dir von den Steinbergern verdient.
Klingel doch mal in Hamburg, da steht sicher ein lecker Käffchen nebst Gebäck für dich bereit,
und dann plaudert ihr mal schön über das Finanzielle, ein guter Job müsste doch auch drin sein? :mrgreen:

Son Mist, ich kann leider nur kreativ und Mukke. Schade.
Würd mir auch so viel selbst programmieren für Cubase… :unamused:
:laughing:

Probier doch mal ob’s bei Dir funktioniert und spende mir dann ein paar Euro und gut is g
Ich nix gemacht wovon Steinberg/Cubase profitiert, sondern lediglich meine Lust, Laune und Spielfreude mit Plugins in allen Plugin Hosts, weil ich mehr an plugins schrauben kann als Dateien zu verwalten.

Nen Keks nehm ich trotzdem gern, vor allem aber Kaffee! g

Ich finde, das ist ein tolle Idee. Ich habe selber viele Jahre in c++ programmiert und kann Deinen Ausführungen ganz gut folgen. Ein GUI hätte ich auch nicht gemacht. Das ist immer das Lästigste an Programmen :wink:
Obwohl ich viel selektiver Plugins installiere, nervt mich dieses Ordner u. VersionsChaos auch. Ist aber auch kein Wunder, wenn der Erfinder von VST gepflegte Ordnerhierachien selber nicht vorlebt und seine Daten munter im System verteilt, damit man sie auch ja nicht wieder findet :wink:
Man ist immer krampfhaft bemüht die Plugins in eine übersichtliche Ordnerstruktur zu zwängen, und scheitert dann doch mit einzelnen Plugins.

Ich werde das auf jeden Fall mal probieren.

Was mich noch interessieren würde:
Wäre es mit deinem Loader (also der, der die richtige DLL lädt) denn grundsätzlich möglich dem Host eine falsche ID vor zu spielen? Liefert der Loader gar selber eine ID? Oder wird der Host fest mit der endgültigen DLL gelinkt und dein loader entfernt, so dass er keinen Einfluss mehr hat?
Es wäre ja denkbar, dass dein Loader selber eine Bridge ist und die ID-“Klärung” abfängt. Hintergrund wäre eben die Tatsache, dass Plugins manchmal neue ID’s bekommen, obwohl es nur simple Updates/Upgrades waren.

Gruss
Michael

Die Loader-DLL ist nicht mal ein Plugin :wink:

Die DLL macht nix anderes als eine DLL zu laden und deren VSTMain-Routine anzuspringen.
Der Name der DLL ergibt sich aus einer txt Datei gleichen Namens im selben Verzeichnis wie die Loader-DLL.

Keine Tricks oder Veränderungen an der ID

Wenn ein Host ein plugin lädt, lädt der Prozess eine DLL per LoadLibrary und ruft als erstes dessen VSTMain Routine auf und bekommt von der routine dann das Plugin-Interface, mit dem er dann ausschließlich arbeitet. In der Loader DLL wird in der VSTmain einfach nur ein LoadLibrary der richtigen DLL gemacht und deren VSTmain-Return-Parameter wird dem Host zurückgeliefert, so dass der Host nicht mit dem Loader, sondern mit der mit dem Loader geladenen DLL kommuniziert…

Total simpel eigentlich, ich bin ja nun wirklich ein C++/Windows-Programmier-Rookie!

…Hintergrund wäre eben die Tatsache, dass Plugins manchmal neue ID’s bekommen, obwohl es nur simple Updates/Upgrades waren.

Das Austauschen der ID würde zu nichts führen außer zu Crashs:
Zu einem Plugin gehört nicht nur das Programm, sondern auch Daten, der Parameterstand des Programms. Der wird ebenso wie die ID im Projekt (und ein Preset ist auch nix anderes) gespeichert. Ein Entwickler der einem Plugin eine neue ID gibt hat wohl einen guten Grund: Inkompatibilität der Datenstrukturen. Oder aber massive klangliche Unterschiede zum “Vorgänger” bei selben Datenstrukturen, was wohl äußerst selten ist, wenn es überhaupt vorkommt.

Wenn jetzt die ID geändert wird schmeckt dem Plugin die Datenstrukturen des eigentlichen Programms ja nicht…

Ein Plugin existiert nie ohne Daten, es würde also immer zu einem nicht vorhersehbarem Verhalten kommen.

Ahhh, ok danke für die Information.
Simpel und auf jeden Fall gut gegen Fehler der unbekannten 3. Art.
Ich hätte da einen Verbesserungsvorschlag… :smiley: .
Nee, lass mal - macht nur Probleme.

Eine Frage habe ich aber noch:
Du schreibst, dass in jedem PluginOrdner (in denen du deine Dll rein geschrieben hast) eine ini-file liegt, in dem ich definieren kann, welche DLL’s bevorzugt verwendet werden soll (x32|ax32a), um das für jeden Host global fest zu legen

Was passiert, wenn ich jetzt nur einen Ordner (als ein Pluginordner für alle meine Host) anlege und dort eine ini hinterlege mit x64|x32.
Jetzt habe ich z.B Kontakt mit deinem Tool scannen lassen und habe in dem Ordner entsprechende x32- u. x64-Aliase in der ini für deinen Loader liegen.
Jetzt linke ich alle meine Hosts (x32 u. x64) auf diesen Ordner.
Wird dann die x64Cubase x64Kontakt laden und x32Cubase nur x32Kontakt (weil es eben x64 auch nicht benutzen kann). Oder würde dein Loader versuchen in x32Cubase eine x64Kontakt zu laden, weil der entsprechende Eintrag in der ini (x64|x32) vorhanden ist.
Würde dein Loader das korrekt erkennen und managen?
(Hoffe, das war jetzt nicht zu kompliziert).

Gruss
Michael

Ja, das ist schon klar. Aber versuchen könnte man es ja. Dieses Problem “fehlendes Plugin” hatte ja jeder schon mal.
Ist normalerweise ja nicht schlimm, wenn es einen Nachfolger gibt. Dumm nur, dass dann das benutzte Preset nicht mehr verfügbar ist. Möchte nicht wissen, wieviele User genau aus dem Grund z.B. Kontakt1-x immer noch installiert
haben.
Aber hast schon recht, wäre sicher nicht ohne Risko, wenn man die ID fälscht.

x64|x32 bedeutet:

Gibt’s für eine Identifier .ini-Datei eine x64 DLL, dann kopiere die x64 Loader-DLL unter dem Namen wie in der Identifier .ini-Datei angegeben, in deren txt-Datei der Pfad zur echten x64 DLL angegeben ist.
Gibts keine x64 DLL, dann nimm den x32 Loader und den Pfad zur echten x32 DLL

Mit dieser Angabe erzeugt man also x64 DLLs für alle Plugins, für die eine x64 DLL vorliegt, und für Plugs für die es keine x64 Version gibt wird eine x32 DLL erzeugt.

Ich würde zumindest für jede Architektur einen Host-Ordner anlegen:
A) Einen mit x64 Plugins und x32 für die Plugs für die es keine x64 Version gibt: “x64|x32”
B) Einen mit x32 Plugins: “x32”

meine App. Ist keine Bridge! D.h. ein Host der A) scannt kann x32 plugs nur scannen/laden, wenn er selbst eine Bridge hat.

Es ist ein reines Organisationstool.

Es macht schlicht keinen Sinn.
Wenn ein Programm nicht auf dem Rechner ist kann es auch nicht ausgeführt werden. So ist das auch mit Plugins :wink:
Was die Preset-Kompatibilität betrifft, das ist niemals eine Host-Aufgabe, sondern liegt im Ermessen des Plugin-Herstellers. Nichts auf der Welt hat darauf Einfluss.

In cubase kann man ja zumindest alte Plugins aus der Menüanzeige verbannen, indem man es bei Plugin-Informationen deaktiviert.

Mit meinen Manager kann man sich ja eine Kategorie “alt” machen und .ini-Dateien alter Plugins dorthin verschieben, das funktioniert dann nicht nur in cubase, sondern auch in anderem hosts: die alten Plugins sind zumindest aus dem Blickfeld und stören nicht mehr…

Ah, ok- verstanden. Dachte, dass die ini von der LoaderDll benutzt wird.
Danke noch mal für die Info. Werde das am WE mal probieren.

Naja, macht schon Sinn - z.B. Kontakt3 könnte ja Kontakt2Presets laden. Und viele andere Plugin können ebenfalls die Presets ihrer Vorgänger laden. Wenn also Cubase nach dem Laden des Nachfolger (Kontakt3 z.B.) das Preset (von Kontakt2) laden würde, müsste es ja theoretisch gehen. Aber das ist halt Theorie. Dazu kenne ich mich zu wenig mit VSt aus.

Müsste man halt mal probieren:

Ein kontakt2-Preset .fxp speichern und dieses .fxp in Kontakt3 laden… Welcher host ermöglicht fxp Laden/sichern?
In einem Preset steckt aber immer auch die ID des plugins mit dem es gesichert wurde, und ich vermute, dass ein Host das Serialisieren von Daten nur dann zulässt, wenn die IDs übereinstimmen - aus Sicherheitsgründen…

Aber ich bin auch alles andere als ein VST-Spezialist. Zumindest könnte ich auch nicht so ohne weiteres mal einen ID Wechsel realisieren :wink: dazu müsste ich mich auch erst mal tiefer einarbeiten…

Nee, IdWechsel ist viel zu heiss. Wird nichts bringen ausser Probleme.

Voodoo,

Du hast’s ja mal laufen lassen…: Hast Du jBridge installiert?
Ich glaub fast, wenn jBridge NICHT installiert ist, werden gar keine DLLs erzeugt, kann das sein?

(Hab ich nie getestet, weil ich ja jBridge installiert hab…)

habs selbst getestet: funktionierte bisher nur, wenn jbridge installiert ist.

Funktioniert jetzt auch, wenn jbridge nicht installiert ist. Hab das Thread-Ausgangsposting geändert, das .zip-archiv enthält die neue Version.

Benutzt wohl niemand ggg Vielleicht schreib ich doch mal ne Anleitung?

Respekt! :open_mouth: