ALTE Waves-Plugins + 64-Bit-Rechner? (CUBASE)

Z

Zotterl

Guest
Auf meinem Rechner (Windoof 10, 64Bit) arbeite ich erfolgreich mit der aktuellen CUBASE LE 8-Version.
Nun besitze ich noch eine uralte CD mit WAVES-Plugins (mind. 15 Jahre alt). Also keine 64-Bit.

Gibt es eine Möglichkeit, diese auf dem neuen Rechner/CUBASE LE8 zum Laufen zu bringen? Oder ist das grund-
sätzlich nicht möglich, da 64-Bit vs. 32-Bit (oder noch weniger)?
 
Versuch macht gluch.

Ich meine mal gelesen zu haben, dass man in 64-Bit-Cubase (eigentlich in allen 64-Bit DAWs außer Ableton Live) 32-Bit-Plugins ohne Wrapper oder sonstiges Zeugs direkt verwenden kann.
 
Cubase hat meines Wissens eine 32-Bit Bridge eingebaut. Schau mal in die Hilfe oder auf die Webseite.
 
psicolor schrieb:
Versuch macht gluch.

Ich meine mal gelesen zu haben, dass man in 64-Bit-Cubase (eigentlich in allen 64-Bit DAWs außer Ableton Live) 32-Bit-Plugins ohne Wrapper oder sonstiges Zeugs direkt verwenden kann.
Hab schon einiges versucht. Z. B. - abgesehen von der "normalen" Installation - die .dll's direkt ins VST-Verzeichnis
zu kopieren. Mir kam auch der Gedanke, dass mit der LE-Version nicht alles machbar ist (?).
 
Wenn ich mich recht entsinne, sind das 32 Bit DirectX dlls. Die werden über das Betriebssystem "gefunden". Herumkopieren der Dateien selbst bringt da nix und verschieben endet schlimmstenfalls damit, dass die nicht mehr gefunden werden.

Bei mir sind die unter Windows 7 x64 in einem Samplitude x86 grottig gelaufen (das ganze OS hängt sich auf). In Samplitude x64 kann ich die grundsätzlich gar nicht laden. Im Gegensatz zu VSTs werden die nicht direkt gebridged, das ginge nur über einen DX -> VstWrapper. Bei anderen DAWs ist das wohl ähnlich, wie ich gelesen hab.
 
Ich kann von der Verwendung jeglicher Bridge auch nur abraten. Mein System (Cubase Artist 7.5 74 auf Win 7 Pro 64) lief erst stabil, als ich mich von allen 32Bit Plugins konsequent getrennt habe. Der Zusammenhang war eindeutig.

Gruß, Arne
 
Cyclotron schrieb:
Wenn ich mich recht entsinne, sind das 32 Bit DirectX dlls. Die werden über das Betriebssystem "gefunden". Herumkopieren der Dateien selbst bringt da nix und verschieben endet schlimmstenfalls damit, dass die nicht mehr gefunden werden.

Bei mir sind die unter Windows 7 x64 in einem Samplitude x86 grottig gelaufen (das ganze OS hängt sich auf). In Samplitude x64 kann ich die grundsätzlich gar nicht laden. Im Gegensatz zu VSTs werden die nicht direkt gebridged, das ginge nur über einen DX -> VstWrapper. Bei anderen DAWs ist das wohl ähnlich, wie ich gelesen hab.

EDIT-Nachtrag: Ich sehe gerade, dass man da tatsächlich DirectX-Komponenten in den *.dll verlinkt hat. Ganz blöde Praxis! Aber vielleicht hilft dieser Link in diesem Kontext weiter:
http://www.soundandrecording.musikmache ... ort-nutzen

Weiter geht es mit dem ursprünglichen Posting von mir, welches nun zu großen Teilen hinfällig ist:

Du meinst ActiveX. Das ist allerdings Schnee von gestern.
DirectX dagegen ist die Microsoft-Schnittstelle für Grafik-, Sound-, Eingabegeräte- und Netzwerkfunktionen.

VST(i)s haben aber weder mit ActiveX, noch mit DirectX etwas zu tun. Nur weil VSTs in der Regel als *.dll realisiert werden, bedeutet das nämlich nicht, dass man diese nicht verschieben dürfte. Eine sogenannte Dynamic Link Library sagt nämlich nur aus, dass diese Programmteile und Daten enthält, die von andere Programme aufgerufen und benutzt werden können. Deswegen funktionieren VSTs ja in diversen DAW-Hosts! Wie diese Programme diese *.dll jetzt nun finden, ist grundsätzlich erst mal deren Problem (z.B. von der DAW, welches in der Regel nach dem VST-Pfad verlangt!) und nicht das Problem des Betriebssystems.

Diese Verwirrung entstammt noch aus den guten alten Windows 95 bis Me-Zeiten, wo das Betriebssystem selbst natürlich ebenfalls auf *.dll in den eigenen (damals noch völlig ungeschützten) Systemordnern zugreifen musste, um elementare Basisfunktionen durchführen zu können. Damals war es ohne weitere Warnung möglich *dll-Daten zu verschieben, zu löschen oder zu überschreiben, was sofort zu schwerwiegenden Fehlfunktionen und Bluescreens führen konnte.

Trotzdem ist es empfehlenswert, VST-*.dll nicht einfach so zu verschieben, da der VST-Installationspfad eben auch in der Windows-Registry hinterlassen wird und womöglich bei Installation einen neuen DAW automatisch abgefragt wird. Es ist ganz grundsätzlich hilfreich, wenn man alle VST-Installationsorte im Auge und im Hinterkopf behält, denn leider gestaltet jeder VST-Programmierer seine Installationsroutinen anders, was zu diversen Installationsorten führen kann. In einem solchen Fall ist es sogar zwingend erforderlich, eine *.dll per Hand zu kopieren (besser als verschieben!), damit diese von der DAW auch gefunden werden kann, wenn nämlich z.B. die DAW nur wenige VST-Pfade zulässt.
 
DerGanner schrieb:
Cyclotron schrieb:
Wenn ich mich recht entsinne, sind das 32 Bit DirectX dlls. Die werden über das Betriebssystem "gefunden". Herumkopieren der Dateien selbst bringt da nix und verschieben endet schlimmstenfalls damit, dass die nicht mehr gefunden werden.

Bei mir sind die unter Windows 7 x64 in einem Samplitude x86 grottig gelaufen (das ganze OS hängt sich auf). In Samplitude x64 kann ich die grundsätzlich gar nicht laden. Im Gegensatz zu VSTs werden die nicht direkt gebridged, das ginge nur über einen DX -> VstWrapper. Bei anderen DAWs ist das wohl ähnlich, wie ich gelesen hab.

EDIT-Nachtrag: Ich sehe gerade, dass man da tatsächlich DirectX-Komponenten in den *.dll verlinkt hat. Ganz blöde Praxis! Aber vielleicht hilft dieser Link in diesem Kontext weiter:
http://www.soundandrecording.musikmache ... ort-nutzen

Weiter geht es mit dem ursprünglichen Posting von mir, welches nun zu großen Teilen hinfällig ist:

Du meinst ActiveX. Das ist allerdings Schnee von gestern.
DirectX dagegen ist die Microsoft-Schnittstelle für Grafik-, Sound-, Eingabegeräte- und Netzwerkfunktionen.

VST(i)s haben aber weder mit ActiveX, noch mit DirectX etwas zu tun. Nur weil VSTs in der Regel als *.dll realisiert werden, bedeutet das nämlich nicht, dass man diese nicht verschieben dürfte. Eine sogenannte Dynamic Link Library sagt nämlich nur aus, dass diese Programmteile und Daten enthält, die von andere Programme aufgerufen und benutzt werden können. Deswegen funktionieren VSTs ja in diversen DAW-Hosts! Wie diese Programme diese *.dll jetzt nun finden, ist grundsätzlich erst mal deren Problem (z.B. von der DAW, welches in der Regel nach dem VST-Pfad verlangt!) und nicht das Problem des Betriebssystems.

Diese Verwirrung entstammt noch aus den guten alten Windows 95 bis Me-Zeiten, wo das Betriebssystem selbst natürlich ebenfalls auf *.dll in den eigenen (damals noch völlig ungeschützten) Systemordnern zugreifen musste, um elementare Basisfunktionen durchführen zu können. Damals war es ohne weitere Warnung möglich *dll-Daten zu verschieben, zu löschen oder zu überschreiben, was sofort zu schwerwiegenden Fehlfunktionen und Bluescreens führen konnte.

Trotzdem ist es empfehlenswert, VST-*.dll nicht einfach so zu verschieben, da der VST-Installationspfad eben auch in der Windows-Registry hinterlassen wird und womöglich bei Installation einen neuen DAW automatisch abgefragt wird. Es ist ganz grundsätzlich hilfreich, wenn man alle VST-Installationsorte im Auge und im Hinterkopf behält, denn leider gestaltet jeder VST-Programmierer seine Installationsroutinen anders, was zu diversen Installationsorten führen kann. In einem solchen Fall ist es sogar zwingend erforderlich, eine *.dll per Hand zu kopieren (besser als verschieben!), damit diese von der DAW auch gefunden werden kann, wenn nämlich z.B. die DAW nur wenige VST-Pfade zulässt.

Zumindest Anfang der 2000er waren das alles DirectX Audio Plugins. Das mit der Shell ist mir schon klar, aber da sie meine DAW und den ganzen Rechner regelmäßig zum einfrieren brachten, habe ich das eben gar nicht mehr weiterverfolgt. Das bisserl Delay und Modulation bekomme ich auch anders hin. Das kann auch an Sam oder der Hardware liegen, persönlich habe ich das Problem seit Sam v8 und dem Wechsel auf Multicoreprozessor. Seitdem haben hier vier Rechner gedient, aber der Ablauf war immer gleich: Beim Playstart hängt sich ein Kern der CPU bei 100% auf und die DAW reagiert nicht mehr.

Das mit dem verschieben von Dlls meinte ich ausdrücklich nur für die DirectX Geschichten, da die unabhängig vom VST Ordner sind und wohl über die Registry zugeordnet werden (kenne mich mit DX nicht aus, programmiere nur "normale" VST Dlls).
 


News

Zurück
Oben