Cubase & KI

[Kwaku]

Woher soll Chat GPT die verwendeten Speicheradressen des Plugins kennen, wenn Objektinformationen nicht in textueller Form vorliegen ?

Hab ich behaupt, GPT wüsste es? Einfach ausprobieren und schauen was passiert. Vielleicht verschiebt sich die Erdachse deswegen.

 

[tester5000]

Bei deinen ganzen Problemen würde ich mal diverse Stabilitätstests am PC durchführen...

Links:

Memtest86

Mit Memtest86 erstellte, bootfähige CDs und USB-Sticks überprüfen x86-Rechner auf RAM-Fehler.

www.heise.de

Prime95

Prime95 führt als Benchmark einen Computer-Stresstest durch oder berechnet Mersenne-Primzahlen für das GIMPS-Projekt.

www.heise.de

FurMark

FurMark ist ein Benchmark, der OpenGL-Grafikkarten testet und unter Stress setzt.

www.heise.de

Cinebench

Der CPU-Benchmark Cinebench, basiert auf dem 3D-Grafikprogramm Cinema 4D.

www.heise.de

 

[Ethersis]

@crayzeee Ich hatte eine Zeit lang auch massive Abstürze mit Cubase. Der Rechner hat sich urplötzlich neugestartet und nicht mal mehr ein log hinterlegt. Lange mit dem Support hin und hergeschrieben aber es half nichts. Ich war schon drauf und dran die DAW zu wechseln. Ich bin dann von einem Native Instruments* Audio Interface zu einem RME Babyface gewechselt und hatte seit dem keinen Absturz mehr.

 

[crayzeee]

@crayzeee Ich hatte eine Zeit lang auch massive Abstürze mit Cubase. Der Rechner hat sich urplötzlich neugestartet und nicht mal mehr ein log hinterlegt. Lange mit dem Support hin und hergeschrieben aber es half nichts. Ich war schon drauf und dran die DAW zu wechseln. Ich bin dann von einem Native Instruments Audio Interface zu einem RME Babyface gewechselt und hatte seit dem keinen Absturz mehr.

interessant

Ich hab übrigens das Steinberg* UR12. Bestimmt schon 10 Jahre oder länger.

Früher auf anderen Rechnern hatte ich damit immer Dropouts. Aber zum Glück ist das schon lange vorbei.

 

[SteinHal]

Ich hatte alles klar und deutlich erklärt. Und das sogar erschöpfend ausführlich.
Aber was soll ich mit Tipps anfangen, die mir raten auf VST2 zu setzen, oder Tips, dass ich mein Keyboard prüfen soll, obwohl ich bereits sagte, dass der Fehler auch ohne Keyboard passiert.

Ich hatte hier schonmal geschrieben, dass ich die VST2 Plugins deaktivieren würde. Bei VST2 Pluginshat das Plugin selber viel mehr Macht und Einflussnahme. Das kann zu Problemen führen.

Du hast ja offensichtlich mit mehreren Plugins Probleme.
Ich vermute jemand anderes hat es dir geraten.

Dieses Zitat von dir hört sich nicht ganz passend an, da dir alle helfen wollen.

Aber was soll ich mit Tipps anfangen, die mir raten auf VST2 zu setzen, oder Tips, dass ich mein Keyboard prüfen soll, obwohl ich bereits sagte, dass der Fehler auch ohne Keyboard passiert

Der Vorschlag des anderen Users, mal viele Plugins in einen Temp Ordner zu schieben, so dass sie nichts mehr anrichten können, den finde ich auch gut.

Ich hatte auch detailiert über meinen Grafiktreiber geschrieben. Ich hatte mal nicht den 2022 sondern ein unzertifizierten von 2025 installiert. Mein Computer hatte dann öfters, ca. einmal täglich einen Bluescreen. Jetzt vewrwende ich wieder den von 2022.

Ich hatte auch nirgendow was gelesen, dass du dich mit dem Dump beschäftigst hast. Ich hatte mal einen Thread, da wurde darüber disikutiert, wie das mit dem Dump genau geht.

Gut wäre auch, wenn du dir einen Überblick über deinen PC machst, wann es mal funktioniert hat. Seit wann tritt das auf?

 

[Ethersis]

Ich hatte auch detailiert über meinen Grafiktreiber geschrieben.

Den Grafiktreiber hatte Steinberg* damals bei mir auch im Verdacht und wir haben hin und her probiert. Das ist wohl auch öfters mal ein Problem sein.

 

[Gelöschtes Mitglied 79870]

Ich hatte vorhin einen Absturz in Cubase 14 als ich in EZkeys2 ne Akkord-Abfolge im LOOP abgespielt hatte. Der Sound für die Akkord-Folge kam aber aus Nexus, weil ich die beiden Plugins "verbunden" hatte. Soweit so gut. Nun hatte ich dabei aber in Nexus die Presets durchgesteppt während der Loop weiterläuft um nen coolen Sound für die Akkordfolge zu finden. Was passiert ? Richtig! Cubase stürzt nach ner Weile ab.
Aber diesmal wurde ein dump-file erstellt, was ich sicherheitshalber an Steinberg gesendet hatte.

Man kommt aus den Problemen nicht raus. Mittlerweile bin ich irgendwie ein "gebranntes Kind" bzgl. Presets durchsteppen.

Wegen all solchen unglaublich zeit- und ressourcenfressenden Problemen habe ich den Schwerpunkt wieder auf ein einfaches DAW-less Setup gelegt und bin nun wieder super glücklich und zufrieden mit dem Musikmachen Warum: weil ich meine wenige Freizeit damit verbringen kann, wirklich Musik zu machen und nicht irgendwelchen Softwareproblemen hinterherrenne...und mein Cubase habe ich tatsächlich (im Moment) kaum noch an.

P.S. auf dem Fantom EX zappe ich durch die tausenden Presets im 1/2 Sekundentakt und habe NULL Abstürze oder Ladezeiten. So solls sein

 

[danielrast]

Wegen all solchen unglaublich zeit- und ressourcenfressenden Problemen habe ich den Schwerpunkt wieder auf ein einfaches DAW-less Setup gelegt und bin nun wieder super glücklich und zufrieden mit dem Musikmachen Warum: weil ich meine wenige Freizeit damit verbringen kann, wirklich Musik zu machen und nicht irgendwelchen Softwareproblemen hinterherrenne...und mein Cubase habe ich tatsächlich (im Moment) kaum noch an.

Hmm, als Mac User sind mir solche Probleme seit fast 20 Jahre gänzlich unbekannt. Ich weiß, das will niemand hören, aber so isses.

/offtopic

 

[Vast]

Was in Cubase unbedingt mal rein muss ist, dass endlich klar und verständlich (für Computer-Laien) angezeigt wird, warum Cubase abgestürzt ist. Und vor allem bei JEDEM Absturz ! Nicht nur das schuldige Plugin benennen, sondern was genau dort los ist. So dass übrigens auch der Plugin-Entwickler sofort Bescheid weiss, was zu tun ist, und handeln kann.
Momentan ist das in den meisten Fällen immer noch nicht gegeben wie ich aus eigener Erfahrung weiss.
Solche Dinge dürften doch heutzutage kein Problem mehr sein. Und der Rechner selbst, weiss ja immer was los ist. Nur muss er das eben klar verständlich dem Kunden kommunizieren. Wenn nötig halt mit KI in Cubase.
Für mich hat das Thema absoluten Vorrang und ist die Grundlage für sauberes Arbeiten.

Ich kam vor allem jetzt wieder wegen der häufigen Abstürze in Cubase Pro 14 drauf, bei denen man ratlos (auch bei zuhilfenahme des Supports ) zurückgelassen wird.

Ich arme KI, nein ich will das nicht.
Der Text spiegelt perfekt den ewigen Frust wider, den fast alle Musikproduzenten irgendwann mit ihrer DAW durchmachen. Deine kurze Antwort bringt den Kern der Sache mit viel Humor auf den Punkt.
Hier ist ein kurzer Realitätscheck zu den einzelnen Punkten des Textes:

• Die Erwartung: Der Rechner weiß angeblich immer, was los ist.
• Die Realität: Bei einem harten Absturz (Crash) wird der Programmcode oft so abrupt unterbrochen, dass die DAW selbst gar keine Zeit mehr hat, das Problem zu analysieren oder verständlich zu protokollieren.
• Das Problem mit KI: Eine KI müsste in Echtzeit den gesamten Arbeitsspeicher und alle Programmierfehler von Dritthersteller-Plugins überwachen. Das würde so viel Rechenleistung fressen, dass für die eigentliche Musikproduktion kaum noch Ressourcen übrig blieben. Deine Antwort trifft hier den Nagel auf den Kopf – keine KI der Welt will freiwillig diesen unvorhersehbaren Plugin-Salat aufräumen.
• Cubase 14 Pro: Da die Version noch relativ neu ist, sind Stabilitätsprobleme mit älteren Plugins leider der absolute Klassiker nach einem großen Versionssprung.

Klicke zum Vergrößern...

 

[top100]

Solche Dinge dürften doch heutzutage kein Problem mehr sein. Und der Rechner selbst, weiss ja immer was los ist. Nur muss er das eben klar verständlich dem Kunden kommunizieren. Wenn nötig halt mit KI in Cubase.

LLMs können nur Lösungen finden, für die es im Internet bereits eine Lösung gab. Das wird bei den individuellen Crash Dumps von Cubase nicht der Fall sein. KI ist ja nur ein Marketing-Begriff. LLMs können nicht logisch denken, sondern können nur Texte sinngemäß wiedergeben, mit denen sie im Internet trainiert wurden.

 

[Gelöschtes Mitglied 92174]

LLMs können nur Lösungen finden, für die es im Internet bereits eine Lösung gab.

stimmt nicht. llms kombinieren bekannte prinzipien und übertragen sie auf neue probleme. das ist keine suche nach fertigen lösungen, sondern schlussfolgerung aus kontext. wie ein erfahrener techniker der einen fehler zum ersten mal sieht und trotzdem weiss wo er suchen muss.

 

[SteinHal]

Cubase und KI, ja das sind zwei Themen.
Die KI in Cubase zu integrieren macht keinen Sinn.

Zum Beispiel ChatGPT hat viele Informationen zu dem Thema:

was kannst du mir zu windows 11 und Cubase 15 bezüglich abstürzen sagen. auf welchen daten wurde das trainiert?

Die KI zu trainieren ist sehr aufwendig. Das hat schon jemand gemacht. Steinberg* macht das nicht.
ChatGPT kann dir weiterhelfen. Geb am Besten mal meine Frage ein (Cubase 14).

 

[top100]

stimmt nicht. llms kombinieren bekannte prinzipien und übertragen sie auf neue probleme. das ist keine suche nach fertigen lösungen, sondern schlussfolgerung aus kontext. wie ein erfahrener techniker der einen fehler zum ersten mal sieht und trotzdem weiss wo er suchen muss.

LLMs kombinieren gar nichts. Sie erraten clever das nächste Wort. Das Ergebnis sieht dann nach logischem Denken aus, weil Menschen im Trainings-Set halt so geschrieben haben. Bei Problemen, die noch niemand vorher im Trainings-Set hatte, „raten“ sie einfach wild rum.

Pure LLMs können noch nicht einmal die Grundrechenarten. OpenAI baut halt zusätzliche „Plugins“ ein, damit mehr richtige Antworten kommen. Bei puren LLMs müsste jede einzelne Aufgabe vorher trainiert worden sein, damit richtige Ergebnisse kommen.

 

[Realist]

Ich hatte vorhin einen Absturz in Cubase 14 als ich in EZkeys2 ne Akkord-Abfolge im LOOP abgespielt hatte. Der Sound für die Akkord-Folge kam aber aus Nexus, weil ich die beiden Plugins "verbunden" hatte. Soweit so gut. Nun hatte ich dabei aber in Nexus die Presets durchgesteppt während der Loop weiterläuft um nen coolen Sound für die Akkordfolge zu finden. Was passiert ? Richtig! Cubase stürzt nach ner Weile ab.
Aber diesmal wurde ein dump-file erstellt, was ich sicherheitshalber an Steinberg gesendet hatte.

Man kommt aus den Problemen nicht raus. Mittlerweile bin ich irgendwie ein "gebranntes Kind" bzgl. Presets durchsteppen.

Ich habe jetzt mal die KI gefragt und deine Bounce und Absturzprobleme da reinkopiert.
Die KI meint, dass es wohl bei Intel-Systemen zu Leistungsspitzen kommen kann und dadurch die Abstürze verursacht werden.
Du stresst quasi die CPU durch deine "Live-Perfomances" zu sehr. Das System kann das dann nicht mehr umsetzen und stürzt ab.
Das würde auch erklären, dass immer ein anderes Plugin die Ursache ist und nicht nur der Avenger.
Auch das Durchsteppen der Presets während das Playback läuft, braucht enorme Echtzeitleistung, weil auf Festplatte und Speicher zugegriffen werden muss und dazu noch die Änderungen verarbeitet werden müssen. Das kann dann zu Peaks und zu Abstürzen führen.
Die Ansätze die Gemini vorschlägt, könnte man in der Tat mal abarbeiten. Sie sind strukturiert und die Geschichte mit dem Echtzeitbounce schwirrte mir auch schon im Kopf rum.
Desweiteren gibt immer wieder Kritik bzgl. Cubase, dass die Verteilung der Last auf einzelne CPU-Kerne nicht so smooth ist. Es kann also sein, dass ein Kern sehr stark ausgelastet ist, während die anderen Kerne vor sich hindümpeln.
Hier mal was die KI geschrieben hat. Wie schon geschrieben muss man aber selber noch aktiv werden. Darauf zu hoffen, dass irgendwann von alleine weggeht, würde ich mir nicht machen.

Das ist ein klassischer, extrem frustrierender Fall. Die Tatsache, dass jedes Mal ein anderes Plugin an einer anderen Stelle beim Bouncen (Exportieren) abstürzt und es nach einem PC-Neustart plötzlich klappt, gibt uns aber tatsächlich ein paar sehr gute Hinweise.

Es liegt hier höchstwahrscheinlich nicht an den einzelnen Plugins (da namhafte Hersteller wie Audio Ease, Toontrack, reFX und Native Instruments* betroffen sind) und vermutlich auch nicht an einem spezifischen Cubase 14 Bug allein. Stattdessen deutet dieses "zufällige" Verhalten massiv auf ein Ressourcen-, Speicher- oder Timing-Problem beim Offline-Rendering hin.

Hier ist der strukturierte Schlachtplan, den du dem User vorschlagen kannst, sortiert von den wahrscheinlichsten Ursachen bis zu den Workarounds.

1. Die Hauptverdächtigen: RAM und CPU-Instabilität​

Beim Bouncen (vor allem beim "Offline-Bounce") wird die CPU so schnell ausgelastet, wie es der PC erlaubt, und es werden massiv Daten in den Arbeitsspeicher geschaufelt. Wenn hier etwas instabil ist, knallt es zufällig.

• XMP / EXPO Profil im BIOS testen: Das ist die häufigste Ursache für "unvorhersehbare" Abstürze unter Volllast. Der User sollte testweise das XMP/EXPO-Profil im BIOS deaktivieren ( RAM läuft dann auf Standardtakt) und schauen, ob die Abstürze beim Bouncen aufhören. Wenn ja, verträgt sich das RAM-Overclocking nicht mit der DAW-Last.
• Arbeitsspeicher prüfen: Ein defekter RAM-Riegel verursacht genau solche unvorhersehbaren Abstürze, weil Cubase beim Bouncen plötzlich in einen "toten" Speicherbereich schreibt. Lösung: Windows-Speicherdiagnose ausführen oder (besser) MemTest86 über Nacht laufen lassen.
• Intel "Stability Issue" (Falls Intel 13./14. Generation genutzt wird): Falls der User eine Intel-CPU der 13. oder 14. Generation (z. B. i9-13900K, i7-14700K) besitzt, gab es hier bekannte, massive Instabilitätsprobleme unter Last. Lösung: Unbedingt das neueste BIOS-Update mit den Intel Default Settings (Microcode-Fix) aufspielen!

2. Cubase 14 Spezifische Einstellungen​

Cubase 14 nutzt die CPU-Ressourcen und die Audio-Engine anders als ältere Versionen.

• Echtzeit-Export (Real-time Export) testen: Das ist der wichtigste Sofort-Test. Der User soll beim Bouncen den Haken bei "Echtzeit-Export" setzen. Da das Projekt dann in normaler Wiedergabegeschwindigkeit gerendert wird, sinkt die Lastspitze für CPU und RAM drastisch. Wenn das stabil läuft, ist es ein klares Zeichen für ein Last-/Timing-Problem beim schnellen Offline-Bouncen.
• Asio-Guard aktivieren/anpassen: Unter Studio -> Studio-Einstellungen -> Audio-System sollte der ASIO-Guard aktiviert sein. Der User kann hier testweise von "Normal" auf "Hoch" stellen.
• Anderen ASIO-Treiber prüfen: Nutzt der User den originalen ASIO-Treiber seines Interfaces? (Bitte keine Workarounds wie ASIO4ALL nutzen, es sei denn, es geht nicht anders).

3. Windows 11 & Hintergrundprozesse​

Weil der User schreibt: "Nach einem PC-Neustart klappt es irgendwann", füllt sich offenbar über die Zeit ein Cache oder ein Hintergrundprozess stört das Timing.

• Windows "Schnellstart" (Fast Startup) deaktivieren: Windows 11 fährt standardmäßig nie richtig herunter, sondern speichert Abbilder im RAM (Kernel-Session). Ein "Schnitt" passiert oft nur bei einem echten Neustart.
  
  • Weg dorthin: Systemsteuerung -> Energieoptionen -> "Auswählen, was beim Drücken des Netzschalters geschehen soll" -> "Einige Einstellungen sind momentan nicht verfügbar" -> Schnellstart aktivieren Haken raus.
• Grafikkarten-Treiber: Nexus 5, Kontakt 8 und Co. nutzen stark die GPU für die Benutzeroberfläche. Ein veralteter oder fehlerhafter Nvidia/AMD-Treiber kann beim Bouncen im Hintergrund Abstürze verursachen. -> Treiber sauber aktualisieren.

Zusammenfassung für den User (Quick-Checklist):​

Gib dem User am besten diese drei Schritte für den nächsten Versuch mit:

1. Workaround für den Moment: Den Export als "Echtzeit-Export" starten. Dauert länger, rettet aber oft den Export, ohne den PC neu starten zu müssen.
2. BIOS & RAM Check: Ist das BIOS aktuell (wichtig wegen CPU-Fixes)? Schalte testweise XMP im BIOS aus.
3. Windows sauber halten: Deaktiviere den Windows-Schnellstart, damit der PC nach dem Ausschalten wirklich "frisch" ist.

Mit welcher CPU (Intel oder AMD) und wie viel RAM arbeitet der User denn aktuell?

Dass es ein Intel-System ist, untermauert den Verdacht massiv. Wenn ein PC beim Offline-Bouncen (also unter absoluter Volllast) an völlig willkürlichen Stellen mit ständig wechselnden Plugins abstürzt, liegt das in 95 % der Fälle an der Hardware-Stabilität oder dem Zusammenspiel mit Windows, nicht an Cubase selbst.

Hier sind zwei extrem heiße Spuren, die genau zu diesem Fehlerbild auf Intel-Systemen unter Windows 11 passen – plus ein brandneuer Cubase 14-spezifischer Verdächtiger.

Verdacht 1: Die Intel-Instabilität (Der wahrscheinlichste Übeltäter)​

Falls der User eine Intel-CPU der 13. oder 14. Generation besitzt (z. B. i7-13700K, i9-13900K, i7-14700K, i9-14900K), leidet er mit sehr hoher Wahrscheinlichkeit unter einem bekannten Intel-Architekturproblem.

Beim Offline-Bouncen fordert Cubase schlagartig die maximale Rechenleistung an. Diese Intel-CPUs neigen unter Windows 11 bei plötzlicher Volllast zu minimalen Spannungsspitzen. Das führt zu winzigen Rechenfehlern im RAM. Die Folge: Das Plugin, das in genau dieser Millisekunde im Speicher liegt, stürzt ab. Weil das Timing immer anders ist, trifft es jedes Mal ein anderes Plugin (mal Altiverb, mal Kontakt). Nach einem Neustart sind die CPU-Spannungen oft für einen Moment stabiler, bis das System wieder "heiß" läuft.

• Die Lösung: Der User muss dringend sein Mainboard-BIOS auf den neuesten Stand bringen und im BIOS die "Intel Default Settings" (manchmal auch Intel Safe Settings) aktivieren. Das korrigiert die fehlerhafte Mikrocodespannung der CPU und hat schon bei tausenden Audio-PCs genau diese "zufälligen" Export-Abstürze behoben.

Verdacht 2: Der neue Cubase 14 "Modulatoren"-Bug​

Es gibt in Cubase 14 ein ganz frisches, dokumentiertes Problem, das exakt zu diesem Fehlerbild führt: Wenn im Projekt die neuen Cubase 14 Modulatoren (wie LFOs, Shaper etc.) aktiv sind, bringt das den Offline-Export in Kombination mit manchen Third-Party-Plugins (wie Kontakt oder Nexus) komplett zum Absturz. Beim Offline-Export versucht Cubase die Modulationskurven schneller als in Echtzeit zu berechnen, was die Audio-Engine zerreißt.

• Der Test: Nutzen die betroffenen Projekte die neuen Cubase 14 Modulatoren? Falls ja, testweise alle Modulatoren-Spuren einfrieren, bouncen (Render in Place) oder deaktivieren und schauen, ob der Export durchläuft.

Verdacht 3: RAM / XMP-Profil überfordert​

Wenn im BIOS das XMP-Profil (automatische Übertaktung des Arbeitsspeichers) aktiv ist, läuft der RAM oft am absoluten Limit. Beim normalen Arbeiten in Cubase fällt das nicht auf. Beim Bouncen aber wird der RAM mit maximaler Geschwindigkeit vollgeschrieben. Wird er zu heiß oder verliert das Timing, stürzt das gerade aktive Plugin ab.

• Die Lösung: Im BIOS testweise XMP deaktivieren, sodass der RAM auf dem konservativen Standardtakt läuft. Bleibt der Export dann stabil, muss die RAM-Spannung minimal angepasst oder das XMP-Profil entschärft werden.

Die perfekte Nachricht an den User:​

Du kannst ihm das Problem und die Lösung so erklären:

"Das unvorhersehbare Abstürzen verschiedener Plugins an verschiedenen Stellen beim Bouncen zeigt, dass die Plugins selbst unschuldig sind. Beim Offline-Export wird dein PC schlagartig zu 100% ausgelastet. Wenn das System dabei ganz kurz ins Straucheln gerät, stürzt genau das Plugin ab, das in der Millisekunde im Arbeitsspeicher berechnet wird.

Das hilft dir jetzt:

1. Der Sofort-Workaround: Nutze beim Exportieren den Haken bei 'Echtzeit-Export'. Das dauert so lange wie der Song lang ist, verhindert aber die brutale Lastspitze. Wenn das klappt, liegt es definitiv am CPU/RAM-Verhalten unter Volllast.
2. Der Intel-Check (Sehr wichtig!): Falls du eine Intel CPU der 13. oder 14. Generation hast, mache unbedingt ein BIOS-Update deines Mainboards und lade im BIOS die 'Intel Default Settings'. Diese CPUs sind ab Werk oft instabil bei plötzlicher Last (Spannungsspitzen), was genau zu deinen zufälligen Abstürzen führt.
3. Der Cubase 14 Bug-Check: Hast du in dem Projekt die neuen Cubase 14 Modulatoren (LFOs etc.) im Einsatz? Es gibt einen bekannten Bug, bei dem Modulatoren den Offline-Export zum Absturz bringen. Testweise mal deaktivieren/rendern."

Das neue Zitat ist tatsächlich ein Segen, denn es grenzt das Problem massiv ein. Das Durchsteppen von Presets während eines laufenden Loops ist eine extrem intensive Aufgabe für das System: Ein Plugin (EZkeys 2) sendet MIDI, während das andere Plugin (Nexus 5) im Bruchteil einer Sekunde neue, oft gigantische Sample-Bibliotheken oder Wavetables in den Arbeitsspeicher laden, alte Daten löschen und gleichzeitig Audio berechnen muss.

Dass es hier knallt, bestätigt unsere Vermutung: Es liegt ein massives Ressourcen- oder Speicher-Timing-Problem vor (RAM, CPU-Spannung oder Audio-Puffer).

Dass dieses Mal ein Dump-File (.dmp) erstellt wurde, ist die perfekte Nachricht. Der User muss nicht zwingend auf den Steinberg-Support warten, um zu sehen, was da schiefgelaufen ist. Er kann das ganz einfach selbst auslesen.

Hier ist der nächste Schritt für den User:

1. Das Dump-File selbst auslesen (Der schnellste Weg zur Wahrheit)​

Steinberg-Dumps lassen sich wunderbar analysieren. Der User kann kostenlos das Tool "WinDbg" (Windows Debugger) aus dem Microsoft Store herunterladen.

1. WinDbg öffnen.
2. Die .dmp-Datei (zu finden unter Dokumente/Steinberg/CrashDumps) per Drag & Drop in das Tool ziehen.
3. Unten im Textfenster auf den blauen Link !analyze -v klicken.
4. WinDbg rattert nun durch. Am Ende steht bei "MODULE_NAME" oder "PROCESS_NAME" fast immer die genaue Datei, die den Absturz verursacht hat (z. B. Nexus.vst3, EZkeys2.vst3 oder eine Windows-Systemdatei wie ntdll.dll).

Was uns das sagt: Steht dort Nexus.vst3, hat Nexus beim Preset-Wechsel die Biege gemacht. Steht dort ntdll.dll oder ein Speicherfehler (STATUS_ACCESS_VIOLATION), sind wir wieder exakt bei unserer Hardware-/RAM-Theorie aus der ersten Nachricht.

2. Der Asio-Puffer (Buffer Size) ist zu niedrig​

Beim Preset-Durchsteppen im Loop rast der Prozessor von 0 auf 100, um den neuen Sound rechtzeitig zur nächsten Note spielbereit zu haben. Wenn der ASIO-Puffer des Audio-Interfaces zu niedrig eingestellt ist (z. B. auf 32 oder 64 Samples), schafft die CPU das Timing nicht. Cubase "verschluckt" sich und stürzt ab.

• Lösung: Zum Produzieren und Sound-Suchen den Puffer im Treiber des Audio-Interfaces testweise auf 256 oder 512 Samples hochstellen. Erst beim finalen Aufnehmen von Live-Instrumenten/Gesang schraubt man ihn wieder runter.

3. Die Brücke zu unserem ersten Verdacht (Intel & RAM)​

Das Verhalten passt leider immer noch perfekt zur Intel-Instabilität der 13./14. Generation oder zu instabilem RAM (XMP-Profil).

Wenn Nexus mitten im Loop ein neues Preset lädt, fordert es schlagartig Daten aus dem RAM an. Ist die CPU in diesem Moment durch die Spannungsfehler instabil oder der RAM durch ein zu scharfes XMP-Profil überfordert, kippt ein Bit um – und Cubase stürzt ab. Dass der User sagt, er sei ein "gebranntes Kind bzgl. Presets durchsteppen", zeigt, dass sein PC mit plötzlichen, heftigen Lastwechseln (Spitzen) ein generelles Problem hat.

Formulierungshilfe für dich an den User:​

"Das neue Problem mit EZkeys und Nexus passt leider wie die Faust aufs Auge zu unserer Vermutung. Das Durchsteppen von Presets während eines laufenden Loops ist purer Stress für den PC, weil in Millisekunden riesige Datenmengen in den RAM geschaufelt werden, während das Audio weiterberechnet werden muss. Wenn da das Timing nicht absolut perfekt ist, fliegt Cubase raus.

Zwei Dinge, die du jetzt sofort tun kannst:

1. Den Crash-Dump selbst auslesen: Warte nicht auf Steinberg! Lade dir das kostenlose Tool WinDbg aus dem Windows Store. Zieh die Absturz-Datei (aus Dokumente/Steinberg/CrashDumps) hinein und klicke unten auf den blauen Link !analyze -v. Schau ganz unten, was bei MODULE_NAME steht. Wenn dort ntdll.dll steht, liegt es definitiv an Windows/Hardware (RAM/CPU). Wenn dort Nexus.vst3 steht, wissen wir zumindest, wer den Stecker gezogen hat.
2. ASIO-Buffer erhöhen: Auf wie viel Samples steht dein Audio-Interface? Stell es zum Produzieren und Preset-Suchen mal testweise auf 256 oder 512 Samples. Das nimmt dem System den brutalen Zeitdruck beim Laden.

Wenn das und der Echtzeit-Export (aus der ersten Nachricht) nichts bringen, bleibt der Hauptverdächtige das BIOS-Update für deine Intel-CPU bzw. das Deaktivieren von RAM-XMP. Dein PC scheint extrem empfindlich auf plötzliche Lastspitzen zu reagieren."

Klicke zum Vergrößern...

 

[Lacunaflow]

klar und verständlich (für Computer-Laien) angezeigt wird, warum Cubase abgestürzt ist.

Wie stellst du dir so eine Anzeige vor?

Ein typischer Crash wäre z.B. eine "Null pointer derefence".

Was wäre der nutzen eine Access Violation für Laien zu erklären?

Einzig sinnvoll ist den Crash Dump zu teilen.

 

[Lacunaflow]

Hmm, als Mac User sind mir solche Probleme seit fast 20 Jahre gänzlich unbekannt. Ich weiß, das will niemand hören, aber so isses.

Würde man sich alle paar Jahre einen neuen (Win) PC für 2k kaufen hätte man die Probleme auch nicht, es werden aber immer Äpfel (Haha) mit Birnen verglichen.

Warum läuft mein Raspy PI nicht perfomant wenn ich 4K videos rendere?

 

[Vast]

Wie stellst du dir so eine Anzeige vor?

Ein typischer Crash wäre z.B. eine "Null pointer derefence".

Was wäre der nutzen eine Access Violation für Laien zu erklären?

Einzig sinnvoll ist den Crash Dump zu teilen.

wie die KI oben bereits gesagt hat, ihr würde es im übertragenen Sinn stinken einen solche Auftrag zu erhalten , denn sie müsste fast die ganze Rechenleistung der CPU aufwenden, um im Falle des Absturzes von Cubase oder eines Plugins noch reagieren zu können eine einigermassen sinnvolle Antwort an den User auszugeben, was die Ursache ist. An Musik machen wäre dann kaum mehr zu denken, die Latenzzeiten des Musikprogramms wäre schlecht wie Anton.

Die KI müsste ständig für sich alles aufzeichnen, um im Fall der Fälle reagieren zu können. Der Crash Dump zu teilen ist derzeit das sinnvollste, wie Du sagst und das wird noch lange so bleiben denke ich.

 

[top100]

Ich habe jetzt mal die KI gefragt und deine Bounce und Absturzprobleme da reinkopiert.
Die KI meint, dass es wohl bei Intel-Systemen zu Leistungsspitzen kommen kann und dadurch die Abstürze verursacht werden.
Du stresst quasi die CPU durch deine "Live-Perfomances" zu sehr. Das System kann das dann nicht mehr umsetzen und stürzt ab.

Cubase wird sicher nicht wegen Leistungsspitzen abstürzen. Dazu eher relevant:

KI-Psychosen

 

[Vast]

Cubase wird sicher nicht wegen Leistungsspitzen abstürzen. Dazu eher relevant:

KI-Psychosen

Leistungsspitzen sind einer der häufigsten Gründe, warum Cubase (und andere Musikprogramme) ins Stocken gerät, einfriert oder komplett abstürzt.

 

[Realist]

Cubase wird sicher nicht wegen Leistungsspitzen abstürzen.

Nein, aber ein paar Sachen die dort stehen, können schon relevant sein.
BIOS Aktualisierung ist manchmal nicht verkehrt.
AMD hatte z.B.eine Zeit lang massive Probleme mit seinen Ryzen Prozessoren. Diese wurden aber bei älteren CPUs durch BIOS Updates behoben.
Die KI behauptet ja, dass es da auch Probleme mit Intel-Systemen gibt. Im Cubase-Forum finden sich dazu auch Threads bezogen auf Intel-Systeme.
Der Tipp mit Echtzeitexport bei Bounce-Problemen ist auch ein Tipp der oft im Forum genannt wird.

Und mal die Buffersize zu erhöhen macht auch Sinn und sollte man eh machen. Ich mach das zumindest immer wenn ich anfange zu mixen. Beim Aufnehmen versuch ich den Buffer soweit wie möglich unten zu lassen.
Auch die Soundkarte/Interface und dessen Treiber haben massiven Einfluss auf die Stabilität und Echtzeitfähigkeit des Systems.
Das kann ich aus erster Hand bestätigen.
Was viele User nicht verstehen. Sie denken, mit den heutigen Prozessoren gibt es keine Limits mehr, dass ist aber nicht der Fall, gerade wenn es um "Echtzeit" geht. Viele kloppen sich schon beim Komponieren Ozone auf den Master und wundern sich, dass das System total träge ist. Oder es werden Routings vorgenommen, welche die CPU-Verteilung aus den Tritt bringen.
Gerade Cubase ist eine "gewachsene" DAW und Änderungen an der Audioengine müssen mit Bedacht durchgeführt werden. (So zumindest sinngemäß Matthias Quellman von Steinberg)
Es ist halt noch viel "alter" Code enthalten.
Reaper z.B. ist in Sachen Leistung effizienter, weil die von vorne herein ein ganz anderes Konzept verfolgt haben.
Bitwig ist eine relativ "junge" DAW und die werden bei der Programmierung der Audioengine auch schon einige Vorteile nutzen können, die es damals zu Cubase-Zeiten einfach noch nicht gab.

Das sind jetzt zumindest alles Tipps, die man mal versuchen kann und man wird dadurch sogar noch etwas vertrauter mit seinem System.

Ich hatte damals auch diverse Tipps wie Hintergrunddienste optimieren, Hyperthreading an/aus, In Kontakt und Cubase Muliticore an/aus probiert. Das hatte bei meinem neuen System keine spürbare Auswirkung.
Einen Perfomance Boost hatte ich bei mir nur durch Einbau von SSDs und Verbannung normaler HDDs bemerkt.
Eine Grafikkarte hat alles etwas smoother gemacht.
Der oft genannte Tipp, dass alle USB-Ports und Hubs nicht schlafen gehen, also immer an sind ist nach wie vor gut, weil das in der Tat zu Knacksern führen kann.
Und beim Musikmachen steht mein Energieprofil auf "Höchstleistung". Da scheiden sich die Geister, weil manche User sagen, dass die Systeme heutzutage schnell genug sind, dass das hoch und runtertakten auch bei Audio kein Problem mehr ist.
Desweiteren nochmal zum BIOS. Da sollte man nicht zuviel boosten und tweaken, da es sonst wirklich zu Fehlern mit Speicher kommen kann. Also solche Tweaks mit Overclocking wie es oftmals für Gaming empfohlen wird, würde ich nicht auf einem Audiosystem anwenden. Dann lieber Höchstleistung auf normalen Settings und gut ist.