VST2 Plugin Manager

Diskussionen rund um unsere Cubase 6 Versionen.

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 7:04 am

Loop Breaker wrote:man muss die example ordner natürlich löschen...


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

Loop Breaker wrote:wenn man den alten
PluginManager\configs\default\hosts\c6\categories und host
erstellten dateien nicht löscht ist das skipt auch nicht sonderlich begeistert...


Ähh, was? *g* erklär mir noch mal genauer bitte ;)

Loop Breaker wrote:this window will close automaticly^^

so der moment naht, spannung.

Man muss jeden ordner einzeln angeben, falls unterordner?


Welche Ordner? Was machst Du denn? *lach*

Loop Breaker wrote: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...


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/<ordner> 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? ;)




Danke für deine Hilfe!!!

Gute Nacht![/quote]
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 8:37 am

Danke Tab Sel!

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

Lg
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 8:47 am

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...
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 9:21 am

Loop Breaker wrote:Danke Tab Sel!

Jetzt ist es mir klar.
Ja ich hab die geautomapten jbridgfiles nochmal mit deinen Tool wrappen wollen...


Ah!

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?
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 9:44 am

Danke! so werd ich dann auch machen :)


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...


Anleitung von Super Dummie f. Dummies:

1) Plugins installieren
2)Automappen (!nicht jbridgen!)
3) dein Tool entpacken
4) in der vstpath.ini die vst pfade rein kopieren
5) in den Host ordner einen Ordner für den besagten host erstellen und in den ordner dann eine Default.ini anlegen.
6) 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:

TabSel wrote:Z.B.:
"x64"
Für einem Pfad mit ausschließlich plugs für die es x64 dlls gibt

Oder:
"x64|x32"

Für einen Pfad mit x64 dlls für plugs die als x64 vorliegen, ansonsten x32 dlls

Oder
"ax64|x64|j64ax32|j64x32"

Siehe dazu auch den englischen Thread bitte...


7) 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?)

Lg
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 10:34 am

Loop Breaker wrote:...Mit den VST pfaden meinte ich die vstpaths.ini und das man alle unterordner einzeln angeben muss?...


Nein, die Pfade die Du in der VSTScanPaths.ini angibst werden rekursiv nach DLLs abgeklappert, d.h. inkl. Unterordner und deren Unterordner etc...

Loop Breaker wrote:...Wenn man shice gebaut hat, und man das .vbs doppelt ausführt...


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 ;)

Loop Breaker wrote:... 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...


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...



Loop Breaker wrote:Anleitung von Super Dummie f. Dummies:

1) Plugins installieren
2)Automappen (!nicht jbridgen!)
3) dein Tool entpacken
4) in der vstpath.ini die vst pfade rein kopieren
5) in den Host ordner einen Ordner für den besagten host erstellen und in den ordner dann eine Default.ini anlegen.
6) 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:

TabSel wrote:Z.B.:
"x64"
Für einem Pfad mit ausschließlich plugs für die es x64 dlls gibt

Oder:
"x64|x32"

Für einen Pfad mit x64 dlls für plugs die als x64 vorliegen, ansonsten x32 dlls

Oder
"ax64|x64|j64ax32|j64x32"

Siehe dazu auch den englischen Thread bitte...


7) das .vbs Tool starten.



... 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...



Loop Breaker wrote:...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?)

Lg


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:
1) native plugins irgendwohin installieren, gegebenenfalls updaten, bei Bedarf mit Automap mappen. Keine Dlls durch die Gegend kopieren/verschieben, ist alles nicht mehr nötig.
2) Auch der jBridger ist nicht mehr nötig, somit auch keine Verwaltung von jBridge-DLL-Ordnern/Dateien, darum kümmert sich das Tool.
3) 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?
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 11:22 am

Achja:

die in der ".\hosts\<hostname>\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*<hostlist>*<DefaultName>

(das * ist ein Trennzeichen, bitte nicht verändern!)

als <hostlist> 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 <DefaultName> 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:<hostname>*<usage>*<name>

für jeden Host (jeden Unterordner in ".\cache\hosts\" gibt es eine Zeile.
Hiermit kann man für einen bestimmten Host im <usage>-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 <name> 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.
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 11:51 am

Im großen und ganzen schon, das einzige was mir noch etwas fadenscheinig erscheint ist:
ajx64x32 und jx64ax32
ist ja das gleiche oder?

Danke noch mal für Deine großartige Leistung!!!
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 12:18 pm

Loop Breaker wrote:Im großen und ganzen schon, das einzige was mir noch etwas fadenscheinig erscheint ist:
ajx64x32 und jx64ax32
ist ja das gleiche oder?


solche Angaben machen keinen Sinn. ;)

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...

klarer?
Last edited by TabSel on Fri Jun 15, 2012 12:40 pm, edited 2 times in total.
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 12:26 pm

Jetzt ist alles klar: Danke!


Anleitung von Super Dummie f. Dummies:
viewtopic.php?f=28&t=23691&start=103

Lg
Last edited by Loop Breaker on Sun Aug 19, 2012 8:44 am, edited 9 times in total.
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 12:36 pm

Danke für Hilfe bei der Anleitung... das ist wohl das Los der Programmierer, Zusammenhänge für Anwender nicht so einfach darlegen zu können... :mrgreen:
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Bassbase » Fri Jun 15, 2012 12:44 pm

Progammierer sind die welche aus dem Koffein im Kaffee Code generieren oder? :lol:

Edit noch was produktive ihr seid die geiisten danke für die Infos und das Tool ;)
Last edited by Bassbase on Fri Jun 15, 2012 1:08 pm, edited 1 time in total.
I7 3.2ghz / Asus P6t deluxe / Asus GTX260 / Rme Hdsp 9632/ Novation 49 sl compact / KRK Rokit 5 / Native Instruments Komplete 7 / Fabfilter Pro q, ....

Just to make sure you know the basics, come here.
Forum Knowledgebase from Users for Users
And if you like this idea or you have more stuff you think a beginner should know about, feel free to PM me so i can take it to the top. Together we know nearly everything...
Forum Knowledgebase von Usern für User Say hello after change
Bassbase
Member
 
Posts: 852
Joined: Thu Nov 03, 2011 8:33 pm
Has thanked: 22 times
Been thanked: 9 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 1:02 pm

Gern, ist doch das mindeste...

Automap ist quasi nur eine halbe bridge welche gerade mal soviel einfluss auf das plugin nimmt das es gerade Parameter auslesen und ansteuern kann... (dll datei wo nur drinnen steht das es eine andere laden soll?)

Jbridge ist dann quasi ein host welcher sich "auf die noch offene helfte" des plugins und automap legt...


Das heist jetzt quasi das jbridge auf den Speicherbereich des Plugins zugreifen kann, (weil automap nur die Speicheradressen verlinkt und dadurch auslesen und VST Parameter steuerbar macht indem es: von den eigentlichen Parameter-Eingang (oder wie das heißt) auf den "Automap Eingang" umschaltet und der host so einfach zur funkstille gezwungen ist)

Cubase kann aber nicht auf den Speicherbereich der geJbridgten plugins zugreifen, weil es nur mit jbridge Speiceradressen arbeitet welche zwar relativ ident mit den Speicerbereich des plugins ist aber dadurch blödheiten von cubase bzw des plugins ausgleichen kann?


Ist es nicht möglich das so zu bearbeiten dass es ein Plugin jeden vst parameter über midi ansprechen kann (mit xy Kurve und so^^:)
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 1:54 pm

Loop Breaker wrote:Gern, ist doch das mindeste...


das Mindeste wäre, wenn wir meine "Arbeit" auch bei Dir zum Laufen kriegen und Du davon profitierst ;)

Loop Breaker wrote:Automap ist quasi nur eine halbe bridge welche gerade mal soviel einfluss auf das plugin nimmt das es gerade Parameter auslesen und ansteuern kann... (dll datei wo nur drinnen steht das es eine andere laden soll?)

Jbridge ist dann quasi ein host welcher sich "auf die noch offene helfte" des plugins und automap legt...


so ähnlich, ja.
Ein Host ist ein Prozess im System. Daten und Code, in einem Speicherbereich. Eine DLL ist ein Stück Code, dass durch einen Prozess in seinen eigenen Speicherbereich hinzuladen kann. Die DLL stellt dem Prozess Unterroutinen zur Verfügung, die dieser Aufrufen kann, der Prozess selbst stellt der DLL Unterroutinen zur Verfügung, die diese Aufrufen kann. Beide, der Prozess und die DLL liegen im gleichen Speicherbereich und können so ungeniert miteinander quatschen. Ein Plugin ist eine DLL, deren Unterroutinen einer bestimmten "Namensgebung" entsprechen muß, das "VST-Plugin-Interface", spezifiziert in den Plugin-SDKs von Steinberg.

Automap ist jetzt, ich nenne es mal so, eine Wrapper-DLL. Ein Wrapper ist eine DLL, die eine andere DLL lädt. Sie fängt die Unterprogramm-Aufrufe, die Kommunkation Host<->Plugin ab, reagiert darauf und/oder leitet die Kommunikation einfach weiter. Eine Automap-DLL, wenn sie ein Host zu sich in den Raum ruft, ruft also eine Plugin-DLL auch dazu in den selben Raum, hört den beiden zu was die so quatschen und sagts der Mama - der Automap-Software, die dann das Mapping zwischen den Hardware-Controllern und den VST-Parametern übernimmt... Die Automap-Software wiederum ist ein ganz anderer Prozess als der Hostprozess, die können also nicht direkt miteinander quatschen, weshalb also die Automap-DLL-Petze dazwischen hockt und "Prozessübergreifend", per Telefon, Zeugs an die Mama weitertratscht. Die Automap-DLL-Petze, die Plugin-DLL und der Host-Prozess sprechen alle die gleiche Sprache (x32 oder x64) und hocken alle im selben Raum. Die Automap-Mama spricht auch irgendeine Sprache (auch x32 oder x64), wohnt aber ganz woanders, und die Petze muß ständig die Mama anrufen und Ihr erzählen was die Plugin-DLL und der Host so zu bereden haben. Am Telefon, so ganz ohne Mimik und so, wird die Information dann auch häufig ein wenig verfremdet wiedergegeben und von der Mama vielleicht falsch interpretiert. Das sind so die Momente wo's mal crasht und sich irgendwer mit irgendwem nicht so recht verstehen mag... ;)

jBridge dagegen ist eine Bridge. Eine jBridge-DLL ist auch erst mal eine DLL, die der Host-Prozess zu sich in den Raum holen, laden kann, sofern sie die gleiche Sprach spricht. Ein x32-Prozess kann nur x32-DLLs zu sich in den Raum rufen, ein x64-Prozess kann nur x64-DLLs zu sich in den Raum rufen. Die jeweilige Bridge-DLL holt aber jetzt keine Plugin-DLL dazu um den beiden zuzuhören. Die hätten sich auch nicht viel zu sagen, weil der eine x32 spricht und der andere x64. Sondern sie greift zum Telefon, hofft dass sie die anders sprechende Plugin-DLL an den Apparat bekommt und übersetzt dem Plugin was der Host so zu sagen hat und übersetzt dem Host, was das Plugin jetzt wieder zu meckern hat.

Loop Breaker wrote:...Ist es nicht möglich das so zu bearbeiten dass es ein Plugin jeden vst parameter über midi ansprechen kann (mit xy Kurve und so^^:)


Klar ist das möglich. gibt es sogar schon...
es gibt ja auch so Zeug wie FXTeleport, Ihrer Mama die Musik über LAN vorspielen, die ein Plugin dem Host vorsingt.
Das sind dann wieder Wrapper, so wie Automap, allerdings sprecht die beiden oben genannten nur x32 ;) Aber man kann ja sicher irgendein natives x32 mit Automap wrappen, dann mit midevice wrappen, dann mit FXTeleport, drauf hoffen dass die Stille Post funktioniert, und dann noch einen Bridger ans Ende hocken der am Telefon dem Host brühwarm irgeneinen Schmarrn erzählt, was den womöglich gar nicht interessiert.

Ich bin ja echt froh, dass Automap als Petze schon recht gut funktioniert und jBridge so ziemlich der beste Simultan-Übersetzer über ISDN-Bildtelefon ist, den es gibt.

Da jetzt noch weitere Petzen und Übersetzer Reise nach Jerusalem spielen lassen? Das muß ich echt nicht haben...

Aus Stabilitätsgründen einerseits, und aus Performance-Gründen andererseits, weil diese Petzen und Telefonterror-Sachen auch alle Hunger haben, ernährt werden wollen und sich auch mal ne Auszeit nehmen, wenn sie Petzen und Übersetzen nicht hinterherkommen...

Auch übrigens: Die Loader-DLLs die ich geschrieben habe, das sind keine solchen Typen. Im Prinzip nicht mal richtige Wrapper. Wenn ein Host diese zu sich in den Raum holt, dann holt die Loader-DLL die Plugin-DLL auch in den Raum, aber der Loader stellt für das Plugin einen Stuhl direkt gegenüber den Host, bleibt zwar noch im Raum, aber legt sich auch gleich in ein Eck zum schlafen, wie ich in ner Teambesprechung. Der Host quatsch also direkt mit dem Plugin, ohne irgendeinen Performance-Unterschied, so, als hätte der Host das Plugin direkt geladen. Es steht halt nur der Stuhl vom Loader im Raum, aber das sind ja auch nur 23 bzw. 28Kb.

(das nur, falls jemand irgendwelche Stabilitäts- oder Performance-Probleme befürchten sollte... es gibt definitiv keine. WENN was nicht funktioniert, dann würde es ohne das Tool und ohne die Loader-DLLs auch nicht funktionieren...)
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Bassbase » Fri Jun 15, 2012 1:59 pm

WOW soviele Infos ;9 so geil und Petzen und Telefonterroristen der Brüller ;)

Grüssli Bassbase
I7 3.2ghz / Asus P6t deluxe / Asus GTX260 / Rme Hdsp 9632/ Novation 49 sl compact / KRK Rokit 5 / Native Instruments Komplete 7 / Fabfilter Pro q, ....

Just to make sure you know the basics, come here.
Forum Knowledgebase from Users for Users
And if you like this idea or you have more stuff you think a beginner should know about, feel free to PM me so i can take it to the top. Together we know nearly everything...
Forum Knowledgebase von Usern für User Say hello after change
Bassbase
Member
 
Posts: 852
Joined: Thu Nov 03, 2011 8:33 pm
Has thanked: 22 times
Been thanked: 9 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 3:07 pm

ich bin sprachlos, Danke!

es hat eh funktioniert, nur nicht halt mit den jbridge.dll...

Die MIdevice VST MIDI Control Extension gehört in Cubase integriert, das wär mal ein Feature was wirklich jeder brauchen kann, der mit den VST Flagschiffprodukt vst`s nutzt,

Eigentlich wäre es genau das gewesen was ich immer haben wollte, nur werde ich jetzt mit Automap großteils Automationen zum Automatisieren nutzen, die meisten Probleme die ich früher hatte hab ich mit Fabfilter VSTs lösen können weil die einfach Midi-haben... aber auch das ist manchmal ziemlich behinder , darum wäre es geil Automations-Spuren zu haben (inkl. insert/sends) welche man sich darstellen lassen kann wie man will (strich/hügel), schneiden, einfärben, umkehren was auch immer kann und das man endlich das so standartisiert das wenn ein Controller ein display hat das auch zur plugin steuerung genutzt werden kann, plug n play, ohne automap oder sonstige zustände, Dann würden hofentlich Controller herauskommen wo jeder Regler ein Diplay hat...


Werd jetzt mal FL antesten, dank Deinen Tool wird jetzt rewire auch kein problem sein :)
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 3:11 pm

Also funktionierts auch bei anderen? Mit Kategorisierung?

Wie geil, freut mich!

Aber: was hat mein Tool mit rewire zu tun? *kopfkratz*
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 3:25 pm

Kann man jetzt nicht das gleiche Plugin in 2 hosts gleichzeitig nutzen?
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 3:31 pm

das konnte man doch schon immer...!?

Du konntest doch schon immer Cubase x64 und z.B. FLStudio gleichzeitig am Start haben, und in beiden Hosts konntest Du das gleiche Plugin so oft verwenden wie Du wolltest...?

TyrellN6 z.B. HEIßT jetzt nur in beiden Hosts auch immer gleich: "TyrellN6", und nicht mehr "TyrellN6 (x64) (Automap)" in Cubase x64 und "TyrellN6 (Automap)" in FLStudio x32. Sondern immer "TyrellN6"
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 3:35 pm

Ich seh gerade in Deiner Signatur: Du benutzt Automap 4.3

Automap 4.3 hat einen Bug: Sonar crasht, wenn Du das gleiche geautomappte plugin mehr als einmal in Sonar instanziierst, z.B.

Womöglich ist das auch so mit mehreren Instanzen eines geautomappten Plugins in mehr als einem Host gleichzeitig? Das hab ich nicht geprüft.

Ist aber auch hinfällig, da Automap 4.4ß1 den Bug bereits gefixed hat...: http://beta.novationmusic.com
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 3:42 pm

ich hatte früher das Problem das ich nicht 2 plugin ordner hatte, und wenn cubase drauf zugreift wollte Live nicht mehr...

Dann wieder fröhlich Betatesten...

Danke für den Tipp!



Lg
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 3:47 pm

Loop Breaker wrote:ich hatte früher das Problem das ich nicht 2 plugin ordner hatte, und wenn cubase drauf zugreift wollte Live nicht mehr...


was meinst Du mit "zugreifen"? Was heißt "wollte nicht mehr"?
Beide Hosts LESEN ja nur die plugin DLL und sperren da nix durch nen Schreibvorgang...

Erklär mal genauer? (Vorausgesetzt Du hast das Problem auch mit meinem Tool noch)...

(Bei Live im Rewire Modus kannst Du eh keine plugins verwenden)
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Fri Jun 15, 2012 4:00 pm

nein, das war damals

Bin leider ziemlich ausgebucht am Wochenende, drum wird der Rewire Test noch warten müssen, muss noch in Laptop herichten mit Cubase...
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

Re: VST2 Plugin Manager

Postby TabSel » Fri Jun 15, 2012 4:05 pm

naja, mein Tool hat mit Rewire ja nix zu tun, lass Dir nur Zeit mit dem Test *lach*

Ich hoffe, und wünsche, dass das Plugin/jBridge/Automap organisieren und kategorisieren in mutiplen Hosts jetzt vollautomatisch per Knopfdruck für Dich funktioniert und Du Dir wie ich ne Menge Zeit sparst und ein schönes, sauberes, einheitliches Plugin-System in Deinem Studio haben wirst.

Schönes Wochenende! :D
Win7x64Prof, Cubase 6 x64
TabSel
Member
 
Posts: 836
Joined: Wed Dec 15, 2010 9:56 pm
Has thanked: 0 time
Been thanked: 7 times

Re: VST2 Plugin Manager

Postby Loop Breaker » Mon Jun 18, 2012 10:51 am

TabSel wrote:
...
(Bei Live im Rewire Modus kannst Du eh keine plugins verwenden)


genau, deswegen hat es nicht funktioniert...
CB7.5 x64, Win7 SP1, RME Multiface II, Intel 5960x, DDR4 4x8GB, ASUS X99-Deluxe, GraKa: ASUS EAH6950 DCII/2DI4S/1GD5, SSDs: 120GB (Samsung - 840 EVO), 120GB (OZC - Vertex 3), HDD: 2TB 64MBcache (WDC WD20EFRX); Fantom Xa, MINIBRUTE, ICON-QCON, BCR2000, BCF2000, zeroSL MKII, padKontrol, Cyborg 3D USB; rewire.dll renamed; loopMIDI, Bidule, jBridge... VSTjunky
User avatar
Loop Breaker
Senior Member
 
Posts: 1292
Joined: Thu Dec 16, 2010 7:52 am
Has thanked: 70 times
Been thanked: 15 times

PreviousNext

Return to Cubase 6 | Cubase Artist 6 | Cubase Elements 6

Who is online

Users browsing this forum: No registered users and 1 guest