Neue Steinbergprodukte nur noch in 64 Bit

  • Ersteller terrablue
  • Erstellt am
Der TX16W oder Alloy 2 bringt Cubase trotzdem zum Absturz, in S1 hingegen damit keine Dramen.
Ist natürlich immer so ne Sache...als reiner S1 User bekomme ich wenig davon mit, ob diese Plugins nun gut oder schlecht programmiert sind, denn in S1 laufen sie ja. Sie müssten sonst ja ständig, oder oft abstürzen, was nicht der Fall ist.
Ich hab eigentlich nicht wenige Plugins (VSTi/ FX), aber die einzigen Sachen die bei mir nachvollziehbar abstürzen sind die, welche mit der jBridge geladen werden, also der 32Bit Kram.
Hab ja schon öfter gelesen, dass das zb. auch Plugin Alliance in Cubase betreffen soll, aber in S1 gibts damit keine Probleme.
Von fast allen namhaften Herstellern (Softube, Slate, Nomad Factory usw.) hab ich da was am Start, aber alles läuft.
Ist daher etwas schwierig zu sagen, ob es nun wirklich an den Plugins, oder an Cubase liegt.
Gut das das Cubase intensiver zu prüfen scheint, aber nutzt ja nichts, wenns nicht läuft.
 
Hab ja schon öfter gelesen, dass das zb. auch Plugin Alliance in Cubase betreffen soll,

Es betraf nicht Plugins von Plugin Alliance generell, sondern deren VST3-Versionen. Das Problem dürfte S1 aber auch haben, denn VST3 ist generell ein heißes Eisen für alle Hersteller.

U-He hat sich z.B. auch mit VST3 schwer getan und da gab es dann auch Abstürze, die es mit der VST 2.x Version eben nicht gab.

Ich kenne im Moment aus meinem kompletten Plugin-Park (32-bit jbridge eingeschlossen) nur ein einziges Plugin, das tatsächlich einen nachvollziehbaren Crash auslöst (und den auch immer):

Das ist GSi VB3, wenn dort das "New 147" Leslie ausgewählt ist. Das Problem dürfte man in S1 aber wahrscheinlich auch haben (habe ich aber noch nicht getestet).

Ansonsten sind die Plugins heutzutage sehr stabil und ich habe wirklich einen riesigen Zoo von so ziemlich jedem Hersteller und teilweise 10 Jahre alt.
 
Es betraf nicht Plugins von Plugin Alliance generell, sondern deren VST3-Versionen. Das Problem dürfte S1 aber auch haben, denn VST3 ist generell ein heißes Eisen für alle Hersteller.

U-He hat sich z.B. auch mit VST3 schwer getan und da gab es dann auch Abstürze, die es mit der VST 2.x Version eben nicht gab.

Ich kenne im Moment aus meinem kompletten Plugin-Park (32-bit jbridge eingeschlossen) nur ein einziges Plugin, das tatsächlich einen nachvollziehbaren Crash auslöst (und den auch immer):

Das ist GSi VB3, wenn dort das "New 147" Leslie ausgewählt ist. Das Problem dürfte man in S1 aber wahrscheinlich auch haben (habe ich aber noch nicht getestet).

Ansonsten sind die Plugins heutzutage sehr stabil und ich habe wirklich einen riesigen Zoo von so ziemlich jedem Hersteller und teilweise 10 Jahre alt.

Plugin Alliance Plugins, alle Versionen ab 2015 crashen bei mir Cubase, alle generell, egal ob nur VST2 und/oder VST3.
Win 7 64 Bit ab Cubase 8.0

GSi 32 Bit? dann verwende doch lieber GSi VB3 die 64 Bit Version :)
 
Ach, weder die Ladezeit der DAW, noch die Ladezeit von Sessions ist im realen Leben ausschlaggebend. Heute fällt doch jeder auf das Marketinggelaber der Verkäufer gewisser DAW-Hersteller rein, nur das er sich danach etwas besser fühlt.
Nur weil das System schneller am Start ist, so heisst das ja noch lange nicht, dass die Produktion schneller fertig ist. Aber genau darum geht es ja. Ansonsten würden wohl kaum weltweit zeitkritische Produktionen zum Grossteil mit PT produziert werden;) Im Gegensatz zu einigen Mitbewerbern wird PT langsamer gestartet. Und wenn die Session etwas komplizierter konfiguriert ist, auch.
Je länger desto mehr denke ich, dass wenn man keine besseren Argumente für einen Umstieg auf eine andere DAW hat, dann wird im Marketing schnell mal die unglaublich schnelle Ladezeit ihrer DAW herangezogen, oder halt das Drag&Drop Feature, oder halt die zwei Klicks weniger, oder halt was weiss ich nicht für unglaublich coole - bis dato noch in keiner DAW vorhandenen Features, welche mir das DAW-Handling gegenüber alteingesessenen DAWs so unglaublich einfacher machen. Ganz klar, sehr Werbewirksam, aber wenn es schlussendlich auf die Finale Produktion ankommt, dann sind solche Argumente nur einfach lächerlich.
 
GSi 32 Bit? dann verwende doch lieber GSi VB3 die 64 Bit Version

Selbstverständlich IST das die 64-Bit-Version.
Der Crash betrifft nur dieses eine Leslie-Modell, was wohl für die Version 1.4 neu dazugekommen war und bereits aus der "kommenden" 2.0 stammte, die dann aber nie kam. Wahrscheinlich hat er da eine andere Library gelinkt (da er zu der Zeit schon angefangen hat, für Crumar Hardware zu entwickeln) und dann crasht es halt.

Wenn ichd as Gefühl hätte, dass an der VB3 noch mal was getan wird, würde ich den Bug an GSi melden. Aber dann kann man auch mit einer Parkuhr reden, fürchte ich.


Plugin Alliance Plugins, alle Versionen ab 2015 crashen bei mir Cubase, alle generell, egal ob nur VST2 und/oder VST3.
Win 7 64 Bit ab Cubase 8.0

VST3 kann ich bestätigen, VST2 definitiv nicht. Ich habe gerade kürzlich ausgiebig die bx_console getestet, da crasht nichts. Ich habe nicht so wahnsinnig viele PA-Produkte, ein bisschen was von Lindell, den SPL TD und den Maag EQ4 und keines davon crasht als VST2.
 
@Rainer_Hain
Welches BS hast Du?
 
@Rainer_Hain
Welches BS hast Du?

Windows 10. Die bx_console habe ich auch nur unter Windows 10 getestet, die restlichen PA-Plugins hatte ich aber unter Windows 8 schon. Ob davon auch noch was unter Windows 7 bei mir gelaufen ist, kann ich aus dem Kopf nicht mehr sagen. Da müsste ich echt nachsehen, wann ich welches Plugin gekauft habe und welches OS ich da hatte.

Das Problem mit VST3 hatte ich allerdings bis vor kurzem immer. Die bx_console ist aber auch das einzige PA-Produkt, bei dem ich überhaupt VST3-Versionen installiert hatte (ich wollte eben auch das testen). Ansonsten habe ich bis vor kurzem die VST3-Versionen immer weggelassen, sofern der Installer das erlaubte.
 
Interessant, Plugin Alliance schreibt das es Probleme ausschließlich bei Win 7 gibt.
Allerdings habe ich nicht nur hier sondern auch in anderen Foren gelesen, dass es auch Probleme unter Win 10 gibt.

Unter Win 7 64 Bit laufen bei mir auch die VST2 Versionen nicht sauber, allerdings nur die Versionen ab 2015.
Alle PA-Plugs, die ich habe (SPL Passeq, bx_meter, Vertigo, VSM3 uvm.) verursachen im Kontext mit anderen Plugins heftige Probleme.
Nutze ich die PA-Versionen aus 2014 läuft alles prima.

Kein Trost bei neueren Entwicklungen wie VSM3.

Interessant auch, nutze ich ein aktuelles PA-Plugin was sicher zum Cubase Absturz führt, in einem Cubase Demo-Projekt, hier sind nur cubase-interne Plugins insertiert, läuft das Projekt problemlos.

Es gibt da ja unterschiedliche Vermutungen woran das liegen könnte (bspw. Zusammenhang mit Fabfilter Plugs)

Aber nichts fruchtet wirklich, bzw. die Ursache für die Problematik unter Cubase ist unklar.
Soweit ich weiß, laufen die PA-Plugs unter Sonar, Sam PRoX2/3 problemlos.
 
Soweit ich weiß, laufen die PA-Plugs unter Sonar, Sam PRoX2/3 problemlos.

Interessant wäre nun, ob die PA-Plugins auf deinem persönlichen Rechner auch unter Sonar und Sam laufen würden.

Das Problem hört sich für mich - zumindest nach dem, was PA selbst dazu sagt - nach einer Inkompatibilität zu irgendeiner Bibliothek an und diese würde ich eher im Betriebssystem vermuten, als beim Host.

Jedes VST-Plugin wird zuerst für und mit Cubase entwickelt, schlicht weil es der mit großem Abstand am weitesten verbreitete Host ist. Ich kann mir daher nicht vorstellen, dass auf dem gleichen Rechner ein Plugin überall läuft, nur unter Cubase nicht. Das wäre der erste Fall, normalerweise ist das immer umgekehrt. Da bei mir die Sachen ja laufen (allerdings habe ich andere PA-Plugins als du im Einsatz), kann ich das leider auch nicht testen. Interessieren würde mich das schon.

Hast du deinen Rechner irgendwie optimiert oder ist dein Windows out-of-the-box?
 
Die neuen PA-Plug Versionen laufen unter Sonar und Sam ProX3 zumindestens bei mir problemlos.
Cubase ist aber meine HAupt-DAW, Sonar und Sam kommen meistens für Fremdmixe zum Einsatz.

Ich habe einige Optimierungen im Bios (C-States, Hyperthreading, etc.) und im BS (Energieoptionen kpl. aus, WLAN, Bluetooth aus, und einige Dienste, habe die Änderungen alle in einem Excel-File dokumentiert, so dass ich nachvollziehen kann, was ich da genau gemacht habe).
 
Die BIOS-Geschichten sind eigentlich unverdächtig (wobei ich bei neueren i7-Rechnern das Hyperthreading eher einschalten würde, bringt bei Cubase ein bisschen mehr Leistung, weil Cubase extrem gut skaliert). Die Energieoptionen sollten eigentlich auch keinen Einfluss haben, aber bei den Diensten würde ich testweise mal alles nacheinander wieder einschalten. Wieder deaktivieren kann man es ja anschließend immer noch.

Ich muss heute Abend mal in meiner Toolsammlung kramen, ich hatte mal ein Tool, dass anzeigen konnte, welche Abhängigkeiten eine dll hat. Dann könnte man mal schauen, welche Betriebssystem- oder sonstige Bibliotheken das Ding erwartet und vor allem beim Laden mal schauen, auf was es am Ende zugreift.

Es muss irgendwo in dem Bereich einen Unterschied geben, an der reinen Host-API kann es eigentlich nicht liegen. Oder besser gesagt: Bei VST 2.x kann es nicht an der Host-API liegen, die ist dafür viel zu simpel gestrickt. Bei VST3 gibt es schon eher Fallstricke, die für diese API spezifisch sind und ich würde auch nicht ausschließen, dass Steinberg sich da selbst ins Knie geschossen hat. Aber VST 2.x ist dafür viel zu "Bullet Proof".

Ach ja, noch eine Idee, da das Problem ab Cubase 8 auftritt:
Hast du den ASIO-Guard für die PA-Plugins im Plugin-Management ausgeschaltet? Es gibt ja Plugins, die den Guard gar nicht mögen, weil da die Latenz nicht mehr systemweit konstant ist.
 
Denke ich auch, die EInstellungen BIOS-mäßig wie WLAN und Bluetooth aus, ahtten bei mir am meisten Performancetechnisch gebracht.
Und, alles stabil, bis auf die PA-Plugs.

Das mit dem Tool klingt sehr interessant, wenn Du es gefunden hast, wäre es nett mir zu kommen zu lassen (via PM).

Steinberg hatte in dem Zusammenhang auch einen ggf. "inkorrekten" Zugriff auf OpenGL seitens des Plugs erwähnt.

ASIO-Guard hatte ich geprüft (soweit ich mich erinnere, kann ich aber nochmal machen).
 
Das Tool, was ich eigentlich im Kopf hatte, finde ich nicht mehr. Kann aber sehr gut sein, dass es zu VC++ gehörte, das ich vor Jahren mal hatte, um selbst ein bisschen Plug-In-Entwicklung zu lernen. Mehr als ein ganz schlimmer 12-stimmiger Chorus ist dabei aber nicht herausgekommen.:)

Ich habe aber mal ein bisschen gegoogelt und es gibt auch einen Freeware Dependency Walker, der alle im- und exportierten Funktionen und Aufrufe anzeigt.

Leider ist der in unserem Fall wenig hilfreich. Es gibt zwar Fehlermeldungen, aber die liegen in der Natur der Sache, weil das Tool nicht wissen kann, welche Funktionen Cubase dem Plugin zur Verfügung stellt. Dann gibt es noch tausende von Windows-Funktionsaufrufen, die meisten aus System und Kernel und der Rest sagt mir überhaupt nichts.

Wenn sich das mal jemand anschauen will, hier gibt es das Tool:

http://www.dependencywalker.com/
 
Wäre zu schön gewesen, dennoch danke für Deine Suche :)

Ich habe mich auf wenige Hersteller begrenzt, mesitens sind es nur zwei oder drei die ich zu 99 Prozent nutze.
Und das hat neben Klang, vor allem mit Stabilität zu tun.

Plugin Alliance gehört für mich nicht dazu ;)
 
Ein gutes Tool ist auch der Prozess Monitor (Procmon) von Microsoft.
Das Prog zeichnet dir alle Aktivitäten auf. Wie das bei dll-Dateien ist weiß ich aber nicht, bzw. ich hatte das nur anhand von NI-Plugins getestet.
Bzw. zu schauen, was eigentlich beim Cubase Start in Verbindung mit NI-Software passiert. Ich hatte das Problem, dass einige Plugins von NI seeehrr lange brauchten um geladen zu werden.
Anhand von Procmon konnte man sehr gut nachvollziehen, wo sich Cubase in Bezug auf NI eigentlich alles bez. der Datenbanken zusammen suchen muss.
Wenn man das Tool nutzt sollte man es aber nur Starten, wenn man eine bestimmte Sache sucht.
Das Programm erzeugt sehr viele Daten.Man kann z.B. auch noch Filter setzen, wenn man weiß wonach man sucht, aber so ganz tief in die Materie bin ich dann doch nicht eingestiegen.
Ich hatte auch mal Cubase geöffnet, dann Procmon gestartet und danach gleich NI Kontakt oder andere NI-Instrumente.
So hat man zumindest schonmal eine Übersicht, was genau in der Zeit, in der Kontakt startet, noch alles so passiert, was sehr aufschlussreich sein kann.
Könnte man in Verbindung mit PA-Plugins dann ja auch so machen.
https://technet.microsoft.com/de-de/sysinternals/processmonitor.aspx
 

Ähnliche Themen

RECORDING-Redaktion
    • Danke
  • Artikel
Antworten
0
Aufrufe
823
RECORDING-Redaktion
RECORDING-Redaktion
RECORDING-Redaktion
Antworten
11
Aufrufe
1K
engineer
engineer
moonbooter
    • Danke
  • Artikel
Antworten
3
Aufrufe
2K
moonbooter
moonbooter

Oft gelesene Themen

Zurück
Oben