VST2 Plugin Manager

Also mein vorhaben war das ich zum beispiel den Minimoog v2.5.1 und den Minimoog Orginal zwitschen kannen bzw beide auswählen kann wenn es möglich ist!

Aber werde noch ein Video machen!


Hier das Video am besten Runterladen weil der zippyplayer spinnt!!

  1. Der Pfad den Du in Cubase einträgst ist falsch:

Trage den Pfad "…Cubase 6.5*categories* ein!

  1. Höchstwahrscheinlich haben die Plugins “Minimoog V” und “Minimoog V Original” die gleiche VST-ID
    (kontrolliere das, z.B. mit VSTHost)

FALLS meine Vermutung stimmt: Für die VST-ID ist der Hersteller des Plugins verantwortlich. Und Cubase ignoriert Plugins mit einer VST-ID, zu der es zuvor bereits ein anderes Plugin gescannt hat. Das kann auch mein Plugin Manager nicht ändern.

Dass Du ZWEI .ini - Dateien hast (“minimoogv.ini” und “minimoogvoriginal.ini”) liegt daran, dass mein Tool mittels des DLL-Namens den Namen der .ini-Datei erzeugt, NICHT anhand der VST-ID. Das hat auch gute Gründe.

Ergo: Für Cubase gibt es immer ENTWEDER das Plugin “Minimoog V” ODER “Minimoog V Original”, nie beide, weil beide Plugs die gleiche ID haben.

Es ist beides das gleiche Plugin (gleiche VST-ID), auch wenn sie unterschiedliche Funktionalität haben, ds entscheidet eben Arturia so. VST-ID-Konflikte sollte es “eigentlich” nicht geben, aber selbst dafür gibt es mit dem Plugin Manager eine Lösung:

Was Du machen kannst um recht einfach (für Cubase) zwischen beiden umzuschalten ist:

A) Kopiere die DLL-Angaben - die letzten Zeilen in der “minimoogvoriginal.ini” mit den Pfaden zu den DLLs hinter die letzten Zeilen in der “minimoogv.ini” und lösche dann die “minimoogvoriginal.ini”
Deaktiviere DLLs in der “minimoogv.ini”, in dem Du in den DLL-Pfad-Zeilen an letzter Stelle (wo jetzt ein “X” stehen müsste) ein “inactive” schreibst, und zwar bei DEN DLLs die Du in Cubase NICHT haben willst. Also entweder in der “Minimoog V.dll” oder in der “Minimoog V Original.dll”.

B) Plugin Manager starten und Dir wird für das Plugin mit dieser VST-ID auch nur die aktivierte Plugin-DLL in den Cubase-Pfad generiert.

Ist zwar ein wenig umständlich, aber wie gesagt, DLL-Konflikte liegen in der Verantwortung der Plugin-Hersteller. WARUM Arturia zwei unterschiedliche Plugins mit unterschiedlichen Funktionalitäten mit gleicher VST-ID rausbringt mußt Du Arturia fragen.

ABER: Du brauchst doch den abgespeckten “Minimoog V Original” gar nicht, wenn Du “Minimoog V” hast. Der “Original” IST nämlich tatsächlich das gleiche Plugin, lediglich einige GUI-Sachen sind beim Original dem User nicht zugänglich. Die VST-Parameter sind dennoch vorhanden(!!), d.h. Songs die Du mit “Minimoog V” machst hören sich mit “Minimoog V Original” absolut identisch an, es ist das gleiche Plugin, und untereinander austauschbar.

Ich würde es machen wie in A) und die Minimoog V Original DLLs dauerhaft “inactive” setzen, den braucht niemand, der den “Minimmog V” hat…

Erst mal vielen dank für die Liebe Antwort von dir :slight_smile:

Was mir noch einfällt und zwar:

Wenn ich angenommen ein Preset speichere (Minimoog v) als VST3 preset und es angenommen in Minimoog (automap) laden möchte klappt das?

Und meine zweite frage ist die Jbridge bietet ja sogenante Performance einstellungen (wenn man die Plugins bridge über die jbridge) ist dieses auch möglich wenn man das über dein Plugin Manager macht?

das ist ja mit ein Hauptgrund warum ich den Plugin Manager geschrieben habe :wink:

Nochmal Cubases’ VST3presets: Wenn Du mit “PluginXYZ” ein VST3preset speicherst, speichert es Cubase in einem Ordner “…/PluginXYZ”. Wenn Du Dir VST3presets für “PluginXYZ” anzeigst, zeigt Dir Cubase den Inhalt des Orners “PluginXYZ” an.

Wenn Du PluginXYZ jetzt automap enablest und Dir Dir dann VST3presets zu “PluginXYZ (Automap)” anzeigen läßt, zeigt Dir Cubase den Inhalt des Ordners “…/PluginXYZ (Automap)” an. Der ist natürlich leer. D.h. normalerweise “siehst” Du die VST3presets des “PluginXYZ” nicht, wenn Du mit “PluginXYZ (Automap)” arbeitest.

Das Automap enablete Plugin “PluginXYZ (Automap).dll” aber kannst Du nicht einfach umbenennen in “PluginXYZ.dll”, da dann Automap nicht funktioniert, das ganze Plugin kann gar nicht erst geladen werden.

Mit meinem Plugin Managerhast Du aber statt “PluginXYZ (Automap)”, das “PluginXYZ” in Cubase zur Verfügung, benutzt aber in Wirklichkeit “PluginXYZ (Automap).dll”!!! Wenn Du Dir dann mit dem automap enablten “PluginXYZ” VST3presets anzeigen läßt, zeigt Dir Cubase den Inhalt des Ordners “…/PluginXYZ” an, und Deine VST3presets sind immer zur Verfügung!

(Cubase speichert/lädt VST3presets in Abhängigkeit vom Plugin-Namen!)

klar.
Wenn ein PluginXYZ mit der jBridge geladen wird, dann siehst Du in diesem Plugin unten links das jBridge-Symbol und einen “Settings” button. Wenn Du auf diesen Button klickst kannst Du die jBridge plugin settings bearbeiten. (Ich hab in diesem Dialog auch noch den Button “edit settings file”, der mir die .jBridge datei, in der jBridge pro Plugin seine settings speichert in einem texteditor öffnet. Ich weiß nicht ob jeder jBridge-Kunde diesen Button hat?)

Wenn ein Plugin mit dem Plugin Manager mittels der jBridge geladen wird, dann hast Du genau die gleichen Funktionalitäten.

jBridge speichert diese settings in einer .jbridge-datei im selben Ordner wird die gebridgte plugin.DLL. D.h. diese Settings gelten pro Plugin, in JEDEM host. Da ich aber mehrere Hosts habe, und ein Plugin mit bestimmten settings in Host A nicht in HOST B funktioniert brauchte ich die Möglichkeit dass jBridge seine settings pro Plugin und pro Hostz speichert, so dass ich unterschiedliche settings pro Plugin und Host haben kann.

Auchg DAS bietet mit der Plugin Manager, in dem ich unterschiedliche Host-Plugin-Pfade generiere.



guck Dir im Übrigen auch mal die “./PluginManager/index.html” an. Nachdem der Plugin Manager fertig ist, liefert Dir diese HTML-Datei einen exakten Überblick über die in die Host-Plugin-Pfade generierten Plugins, und u.a. auch die direkte Pflege der jBridge-settings textdatei…

Danke! nochmal für
die Hilfe!!!
und den Plugin Manager!!!

Ich weiß nicht ob jeder jBridge-Kunde diesen Button hat?
haben schon nur funktionieren tut er leider nicht. jetzt weis ich wieder was ich gestern vergessen habe :smiley:

Bitte :wink:

GUI gefällig?

wozu?

Vielleicht findet er dann mehr Anklang :wink:

Ich glaube der example ordner ist eher das “Problem”.
es gibt nichts geileres als einen texteditor wo man einfach copy&pasten kann strg+s und fertig…



Lg

TabSel`s VST2 Plugin Manager: (Anleitung für x64 User [da meist komplizierter])
http://www.familiekraft.de/PluginManager/
und unbedingt den examples Ordner auch runterladen…


Obwohl wir mit einer der besten Musik-Programme (betrifft alle) der Welt arbeiten, sind wir oft gezwungen maßnahmen zu ergreifen, um den VST-Host zu umgehen. zB mit:
MCX http://www.midevice.com/Products.aspx?ProductID=0) oder
Automap http://www.novationmusic.com/products/midi_controllers/zero_sl_mk_ii/
oder mit diesen hier um geautomapten-Presets in nichtautogemappten Presets zu haben, schöne Pluginnamen, ungehemmt sortieren zu können, das jbridgen abnimmt, und zB automatisch nur die geautomapten nimmt, jbridgt, “um dingst” dass sie wie normale aussehen aber automap sind, und dann schön übersichtlich bei bedarf unterordnen kann (was mann nicht muss weil das auch der Pluginmanager macht [im Explorer verschiebt man EINMAL alles in die Ordner die man will und dann kann man diese “Konifutartion:)” auf jeden System verwenden)…

aber wenigstens haben wir ja schon alle JBridge installiert da wir ja sonst nicht mehr als 64 Stück vst.x32 plugins sogar noch in Cubase 6.0.7 (x64) pre release verwenden können ohne das es abschmiert.

Das mach uns dank installierter jBridge und VST2 Plugin Manager das Leben schöner.
wenn man Automap u. jBridge verwendet. (und überhaupt bei mehreren Hosts und mit verschiedenen Bit…)

Da die Automap Mama eine 32 Bit Anwendung ist sollte man bevor man jBridgt (was aber für uns jetzt der PluginManger macht) b.z.w. den PluginManager verwendet, Automap die Plugins automappen zu lassen, da das Tool, Automap nicht dazu veranlassen kann, jBridge hingägen lässt sich von den Tool steuern und übernimmt absofort der VST2 PluginManager von TabSel…

Automap ist auch keine richtige Bridge und macht idR keine Probleme, ausser bei gecrackten vl…
und da die AutomapServer.exe *32 ist: braucht ein 32Bit plugin “zwei Telefone” weniger…lange Geschichte: VST2 Plugin Manager - Auf Deutsch - Steinberg Forums
außerdem was noch vl. viel schlimmer ist, ist dass Cubase dann einen eigenen Automap Preset Ordner für Jede Plugin Endung (zB: Automap) anlegt und alle alten presets wären nur im nicht autogemappten plugin zu verfügung und umgekehrt, außerdem hat man dann wieder das plugin 2x vorliegen (1x automap 1x normal). Wenn man zuvor automapt hat man dann (nach wunsch) nur eine Version von den Plugin geautomapt aber ohne der behinderten Automap endung das Cubase dazu veranlasst einen anderen Preset Ordner zu verwendet (wie es normalerweise der Fall wäre)…

Nach dem eigentlichen installieren der Plugins Automappen bzw. MCXen …
und den Rest (u.A.jBridgen) übernimmt TabSel`s VST2 Plugin Manager.
gilt wie gesagt für x64 user weil Automap u. MCX eigentlich 32Bit Anwendungen sind

32Bitler brauchen sich ja wahrscheinlich auch weniger Gedanken machen. **Versucht nicht das Toll mit jBridg.vsts zu füttern, das will es selber machen…**


Anleitung von Super Dummie f. Dummies:

  1. Plugins installieren,
  1. Automappen (!nicht jbridgen!

  2. TabSels VST2 Plugin Manager entpacken (in den Examples ist die vstpath.ini u. der Host Ordner…)

  3. in der vstpath.ini die vst pfade rein kopieren

  4. in den “Host” Ordner einen Ordner für den besagten Host (zB. Cubase) erstellen und in den ordner dann eine Default.ini anlegen.

  1. Default.ini zB:
    ax64|j64ax32
    reinschreiben, dass das scipt weis was es für den jeweiligen Host tun soll mit: | trennt man die einzelnen Optionen:
  1. das .vbs Tool starten.

    \
  2. unter C:\vst\PluginManager\configs\default\cache\categories
    kann man die Plugins katigorisieren…


    Lg

Warum kann der Pluginmanger keine gejBridgten automap.dll`s managen?

MsgBox oFile.Path & " is a jBridged Plugin DLL. jBridged automapped or jBridged native Plugin DLLs are not supported. Please automap your native Plugins instead!", , “VST2 Plugin Manager”

Lg

Er bridged selbst. Konzept.

Kann man es trotzdem irendwie machen das man zuerst jbridgt und dann automapt?

Lg

Klar. Nutz nur (j…)x… mit meinem Manager und verwende diese Pfade in der Automap software…

Allerdings: wenn Du mehrere Pfade hast mit gleichnamigen Plugins, und Du Automap enablest es, dann lädt der Automap wrapper nur das letzt gefundene, d.h. Du hast keine verschiedenen jbridge settings eines Plugs in verschiedenen hosts.

Ich hab mir schon was dabei gedacht mit meinem Konzept…

:wink:

v. hat automap keine files anglegt als ich dein Tool drüber laufen lassen habe aber mir kommt vor dass das die FM die ich oben gepostet habe zur folge hatte.

Hab den neuen examples Ordner von dir heute erst runter geladen und muss sagen der ist Toll. Hab einfach den 64Bit auf C6 umbenannt, die anderen gleöscht, meine paar vst pfade eigetragen, und hat wunderbar funktioniert, bis halt auf die wenigen gejbridgten.

Edit: die was funktioniert haben waren die meisten auch jbridge, aber ich wollte was spezielles machen, und die wolt ich vorher selbst jbridgen…

Ich Automap enable ALLE Plugins.
Ich hab etwa 10 hosts Ordner, für jede App. die Plugins hosten kann einen.

Und per Doppelklick hab in zwei Minuten alle Plugins in allen Host Ordnern fein säuberlich categorisiert und bei Bedarf gebridged. Unterschiedliche Jbridge settings in den Hosts, bleiben erhalten wenn ich Plugins umkategorisiere.

Ich installiere/Update plugs ein mal. Wenn für ein Plug eine x64 Version rauskommt wird diese automatisch verwendet.

Für mich ist das perfekt so. Kein Aufwand mehr.

So bei mir funktioniert es jetzt auch wie bei dir, hab jetzt nach Hardware-Upgrade neu installieren müssen, aber hat sich ausgezahlt, weil ich mir das:
Katogoriesieren (alte config: PluginManager\configs\default\cache\categories)
JBridgen (macht auch der Pluginmanager)
und Automap Desaster dank Deines Pluginmanagers ersparrt habe, und sicher in Zukunft auch noch viele Nerven sparen wird…

Ich kann jetzt nach einiger Testerei behaupten das dein PluginManager einer der besten MusikProgrammTools der Welt ist, weil auch Idioten wie ich damit Extrem einfach Automap, JBridge und VST-Plugins in den Griff bzw. in den Ordner wo wir sie reinhaben wollen, reintun können und die “Konfigurationen” speichern um auf ein anderes System zu übertragen und dort nichts mehr sortieren oder umbenennen etc. zu müssen
nur mehr Jbridge und plugins installieren (nicht jbridgen)), alle plugins automappen, Pluginmanager ausführen, fertig:
dann
hab ich alle plugins geautomapt als 64bit vorliegen und auch nur diese in Cubase, schauen aber so aus als wären sie nicht geautomapt…

Wenn einmal ein Plugin dazu kommt braucht man nicht einmal einen Ordner öffnen weil man gleich im Pluginmanager kategorisieren kann wenn man will, was bei einzelnen Plugins perfekt ist, wenn man es zum ersten mal macht würde ich aber: PluginManager\configs\default\cache\categories bevorzugen weil man im Explorer strg+auswählen, strg+x und so machen kann…

Nochmal 1000 Dank dafür TabSel!!!


Lg

Danke, gern geschehen. :slight_smile:

Auch wenn der Thread schon etwas älter ist, wollte ich mich nur mal schnell für diesen tollen VST2 Plugin Manager bedanken, der mir in Zukunft viel Arbeit ersparen wird. Ich denke, so lange es keine vergleichbaren Möglichkeiten für VST3 gibt, wird VST3 noch lange ein Nischenprodukt bleiben. Ich z.B. nutze VST3 nur für 2 Plugins die Sidechain benötigen. Bei allen anderen Plugins stört mich die Bevormundung mit der festgelegten Kategorisierung.

Anyway: ich hab nicht den ganzen Thread gelesen, aber wenn ich dennoch ein paar kleine Anregungen zu dem Plugin Manager hier abgeben dürfte:

  • die Zwischenordner ‘configs/default’ sind ja mehr oder weniger leer und erscheinen mir daher etwas redundant. Wäre es nicht möglich, die Ordner ‘cache’ und ‘hosts’ direkt in das Rootverzeichnes des Managers zu legen und sich diese beiden Zwischenstationen zu sparen?

  • Die Änderung der Plugineinstellungen (z.B. Ändern des default Namens etc.) in den jeweiligen ini Dateien ist ein wenig umständlich, da man hierfür jede ini-Datei einzeln aufrufen muss. Vielleicht wäre es besser, eine einzige ini-Datei für alle gefundenen Plugins anzulegen, die man dann leichter mit einem Texteditor bearbeiten kann. Dadurch würden aber vermutlich die Drag&Drop Möglichkeiten wegfallen… :confused: Schick wäre natürlich ein graphisches User Interface, das alle diese Möglichkeiten eröffnet. Vielleicht als Donation- oder Shareware… :wink:

schöne Grüße und nochmals besten Dank für dieses hilfreiche Werkzeug,
andi