S1 v2 + Melodyne weiterhin instabil

[d]
Nach Erfahrung klingt das für mich nach RAM
Leider nein, der ist in Ordnung.[/d]

Sorry, verlesen.
jojoon hat's aber an meiner statt ein Posting weiter unten aber ganz gut hinbekommen. ;)
 
RAM, der mit der Zeit zugelaufen ist. Also dort würde ich mal ansetzen. Nur son möglicherweise helfender Gedanke.

Wie hilft mir das?
Das klingt eher nach nem Speicherleck?

Was soll ich dagegen tun? - alle halbe Stunde den Rechner neu starten?
 
Wie hilft mir das?
Das klingt eher nach nem Speicherleck?

Was soll ich dagegen tun? - alle halbe Stunde den Rechner neu starten?
Naja das hilft insofern, dass man erstmal weiss, woran es liegen könnte. Dann kann man auch aktiv dagegensteuern. Man muss halt immer mit seinen Ressourcen haushalten, die einem zur Verfügung stehen, das ist ja auch normal soweit.

Ein Leck muss dann trotzdem - ganz klar - von uns geschlossen werden!
Vorher muss es allerdings gefunden werden.

Seit dem letzten Update und dem Matchen der Versionen, die nur noch so mit einander funktionieren (S1 2.0.6 + Melo 2.1) sollte eiiiiigentlich ein massives Speicherproblem gelöst sein. Da wissen aber die Celemonier mehr, weil wir haben ja nichts mit deren Engine ansich zu tun!

Ich kann immer nochmal wieder raten:
Strophe für Strophe in einzeln gebouncten Events zu bearbeiten.

Grüße
Ari
 
Ich kann immer nochmal wieder raten:
Strophe für Strophe in einzeln gebouncten Events zu bearbeiten.

Gilt das jetzt generell für sowohl 32bit als auch 64bit Version von Studio One? Oder lässt sich in der 64bit Version mehr ausreizen (bei größerem Arbeitsspeicher natürlich als 4 GB)?
 
Seit dem letzten Update und dem Matchen der Versionen, die nur noch so mit einander funktionieren (S1 2.0.6 + Melo 2.1) sollte eiiiiigentlich ein massives Speicherproblem gelöst sein. Da wissen aber die Celemonier mehr, weil wir haben ja nichts mit deren Engine ansich zu tun!

Na dann muss er einmal dort anklopfen, denn:

Man muss halt immer mit seinen Ressourcen haushalten, die einem zur Verfügung stehen, das ist ja auch normal soweit.

Die Ressourcen sollten mit 4 Stems (die nicht bearbeitet werden) und einem Vocaltrack mit da und dort ein paar Takes eigentlich locker zurecht kommen bzw tun sie das ja auch - ohne ARA.
 
Gilt das jetzt generell für sowohl 32bit als auch 64bit Version von Studio One. Oder lässt sich in der 64bit Version mehr ausreizen (bei größerem Arbeitsspeicher natürlich als 4 GB)?
Also Celemony selbst empfielt ausdrücklich die 64 Bit version. Hab ich selbst mal irgendwo beim Surfen gelesen. Wer also weniger benutzt, als die eigenen Hersteller-Empfehlungen, muss mit Problemen rechnen.

So jetzt aber mein persönlicher Erfahrungsbericht: Da ich fast ausschließlich ein 32-Bit User bin, weiss ich und kann (für mich und mein System) bestätigen, dass auch diese kleine Bit Version wirklich problemlos funktioniert.


Falls solche Probleme wirklich arg häufig vorkommen, könntet ihr mir mal ein komplettes ganzes Projekt zum Testen und Anschauen mitgeben. Wenn es hier läuft, dann liegts am System. Es KANN aber auch sein, dass es hier ebenfalls kaputt ist und hackt, dann ist was im Code nicht korrekt und muss gefixt werden.

Das war jetzt ein Angebot. ;)
Ari
 
Kann man das vielicht in einem Log nachvollziehen, bin leider kein Windows-Experte, beim Mac gibt es crashlogs, wenn was in de Hose geht.

Evtl., wie heisst das noch, Systembericht(?), vielleicht legt Windows mit etwas Glück dort was ab.
 
Wenn es ein Crash gibt, dann gibts auch ein Crashdump.
Diese .dmp Datei befindet sich bei Windows 7 :

C:Benutzer/Benutzername/AppData/Roaming/PreSonus

(Hinweis: der Ordner ist versteckt)

Anhand dieser Datei können wir gucken, wo genau es zum Crash kam. Und möglicherweise auch, warum.

Ari
 
Studio One ist ja nicht abgestürzt sondern eingefroren. Eine Dump-Datei wurde nicht erzeugt. Die letzten Dumps, die bei mir herumliegen, sind von Anfang Juni.

Ich hatte eine Bass-Spur mit Melodyne bearbeitet, danach für eine Schlagzeugspur und die angepasste Bass-Spur die Transientenerkennung aktiviert, die Bass-Spur im Editor geöffnet, im Arrangier-Fenster Transiente für Transiente überprüft, ob Deckungsgleichheit mit der Schlagzeugspur bestand und dort ggf. gerade gezupft. Waren Transienten für den Bass falsch erkannt worden, habe ich sie im Editor entfernt oder verschoben.

Speichermangel (also ein Memory Leak in Studio One und/oder Melodyne) kann kaum die Ursache für das Einfrieren gewesen sein (und äußert sich auch eigentlich nie so), da der Rechner völlig flüssig lief und keinerlei Swapping erkennbar war.

Es deutet für mich eher auf einen Fehler in der Ressourcenverwaltung hin, d.h. ein Deadlock, verursacht durch konkurrierende Thread-Zugriffe, die nicht sauber synchronisiert sind.

Schöne Grüße,
Steffen

P.S.: Ari, mache Dir vielleicht mal häufiger klar, dass Du hier mit Kunden sprichst, an denen Presonus Geld verdient! Und fühle Dich nicht ständig angegriffen, wenn jemand auf Verbesserungspotenzial in Studio One hinweist - sieh es lieber als Chance. Als Mitarbeiter der Qualitätssicherung ist es Deine Aufgabe, Fehler zu FINDEN, und nicht, sie zu leugnen!
 
Heisst einfrieren, das S1 aussetzt und sich wieder faengt oder musst du es ueber Windows abschiessen ("Programm reagiert nicht mehr: Beenden / Warten auf Antwort. / noch irgendwas")?


gruss, Chris
 
Speichermangel (also ein Memory Leak in Studio One und/oder Melodyne) kann kaum die Ursache für das Einfrieren gewesen sein
Ein Speicherleck hat nichts mit der Menge an Hauptspeicher zu tun. Ein Speicherleck (Memory-Leak) kommt zustande, wenn z.B. ein Programm etwas in den Speicher packt und sich nicht drum kümmert, ob der Speicherplatz auch wieder dem Host (DAW,OS) wieder zur Verfügung gestellt wird, wenn es sich beendet. Es gibt auch noch andere Ursachen, die explizit michts mit dem Programm zu haben, sondern schon auf OS-Ebene eine Rolle spielen.

Das ist allerdings relativ einfach dargestellt!

Ich habe jetzt nicht gelesen, auf welchem System du unterwegs bist (Windows?), aber ein Einfrieren hat leider sehr, sehr oft seine Ursache im Hauptspeicher himself. Auf meinem iMac (niegelnagelneu, Original Apple-Speicher) musste z.B. Speicher getauscht werden, eben weil der einfach einfror. Seitdem habe ich Ruhe im Karton.

Edit :
Gut, dass du den Hinweis Einfrieren gegeben hast! Da kann in der Tat der willigste Computer, das beste OS keinen Dump oder Log mehr schreiben. Windows 7 und OSX Lion sind mittlerweile so gut, dass sie Programm, die in irgendeiner Form rumzicken, isolieren können (Win7 hat auch da noch seine Problemchen) und du über den Taskmanager immer die Möglichkeit hast, den Prozess, also das Programm abzuschiessen.

Es gibt eine Ausnahme. Schafft es das Programm, also in unserem Fall die DAW, ganz gezielt (oder zufällig) Bereiche im Arbeitsspeicher zu penetrieren, ja auch dann folgt ein Freeze..... Ist aber eher selten der Fall.

Also : Crash = Windows oder OSX laufen weiter, Einfrieren = OS so gut wie unschuldig.
 
@Chris:
Siehe ganz oben, erster Beitrag im Thread! Studio One musste abgeschossen werden.

@Einfach:
Ein Speicherleck (in Studio One oder Melodyne) führt zur Reduktion des Hauptspeichers, was letztlich dazu führt, dass der Rechner swappen muss, weil der nötige Speicher fehlt.

Speichermangel führt aber nur in seltenen Fällen (Programm fragt in Endlosschleife nach Speicher, kriegt ihn nicht, fragt wieder, kriegt ihn nicht ...) zu Hängern. In der Regel führt es eher zum Absturz, da im Normalfall nicht für jedes Objekt, das via new-Operator angelegt wird, explizit geprüft wird, ob der benötigte Speicher auch zur Verfügung steht.

Programmhänger deuten in fast allen Fällen auf Schleifen im Programm hin, deren Abbruchbedingung nie erfüllt wird. Und das sind so gut wie immer Programmierfehler, die man finden und durch entsprechende Tests absichern muss.

Bei Thread-Geschichten sind Unit-Tests kompliziert bis gar nicht realisierbar (kommt auf den Einzelfall an). Hier sind Integrationstests und Anwendertests erforderlich (Anwender meint in diesem Fall natürlich die Testabteilung, nicht den Kunden).

Wir als Kunden können unseren Beitrag leisten, indem wir auf Symptome hinweisen. Auch bei der Fehleranalyse können wir helfen, wenn man uns die richtigen Fragen stellt. Den Code müssen sich aber die Programmierer schon selbst ansehen und die richtigen Schlüsse aus allen verfügbaren Informationen ziehen.

Entscheidend hierbei ist natürlich der Wille, das auch zu tun und Kundenhinweise mit Wohlwollen anzunehmen, anstatt die Kunden als Idioten abzustempeln.

Schöne Grüße,
Steffen
 
Sorry, das ich da wiedersprechen muss!!!

Selbst eine Schleife zwingt den Rechner zwar in die Knie, führt aber in den wirklich seltensten Fällen zum Einfriren des Systems! Eigentlich gar nicht. Wenn man Geduld aufbringt, kann man sehr wohl erkennen, ob der Rechner wirklich steht, eingefroren ist, oder ob er sich nur gaaaaanz langsam "bewegt". Das ist schon ein Unterschied!

Sowohl Windows, als auch OSX Programme laufen heutzutage in einem, vom OX zugewiesenem Speicherbereich. Nein, nicht nur heutezutage, das war schon fast immer so, nur sind die Möglichkeiten eines Programms heutzutage das Sysem zum Einfrieren zu bringen, schon echt minimalisiert worden. Treiber, wie z.B. die der Soundkarte sind u.U. sehr wohl in der Lage, diese zu tun, weil sie auf einem anderen Level innerhalb des OS laufen.

Ich sage ja auch icht, dass es unmöglich ist, das Studio One, bzw. melodyne da Murcks machen, aber wird schon verdammt eng, dass zu beweisen. Auch der Hinweis, dass kein Dump geschrieben wurde, zeigt schon, dass das OS nicht weiterarbeiten konnte.

Du spricht die Garbage-Collection an. Selbst das ist in KEINEM, heute aktuellem OS gewährleistet, dass diese zeitnah ausgeführt wird, das liegt einzig im Ermessen des OS und NICHT dem Programm, wann es den HEAP (ein Bereich, der einem Programm für bestimmte Dinge zugewiesen wird) abräumt.

Und nein, unter Win7 oder OSX führt eine Endlosschleife nicht zum völligen Einfrieren des Rechners, er wird nur uuuuunheimlich zäh.

Im Kern werden sowohl melodyne, als auch Studio One in C oder C++ geschrieben worden sein (Schuss in's Blaue), das GUI-Gefrickel u.U. in Objective-C oder Visual C, keine Ahnung. Das sind Geheimnisse, die jede Firma hat ;)

Selbst wenn du in den aktuellen Betriebssystemen versucht, mit C verdammte Schweinereien zu machen, dann wird das relativ flott vom OS erkannt und dein Prozess isoliert. Hacker nutzen die Schwächen der Betriebsysteme an genau diesen Stellen aus.

Ein Programm bekommt schon seit DOS 3.3 (frühere kenne ich nicht) einen Speicherbereich zugewiesen, in dem es sich austoben kann. Unter Win7 und OSX werden genau diese Grenzen mehr oder weniger ständig untersucht und ggf. das Programm gekillt (das Programm wurde beendet, neu starten, bericht, ignore).

Wir als Kunden können unseren Beitrag leisten, indem wir auf Symptome hinweisen. Auch bei der Fehleranalyse können wir helfen, wenn man uns die richtigen Fragen stellt.
Und da liegt das Geheimnis, wie der Support tickt. Ein User ist normalerweise defintiv nicht in der Lage, eine so spezifische Frage zu stellen, dass u.U. ein Entwickler, und bei dem landet es letztlich, da etwas mit anfangen kann.

Es ist eine Crux :) Aber wenn du die Möglichkeit, mal den Speicher zu tauschen, würde ich das erstmal in Betracht ziehen.
 
@Einfach:
Entweder, ich bin zu platt von der Arbeit, um mich verständlich auszudrücken, oder Du liest nicht richtig! ;)

Ich habe zu keinem Zeitpunkt etwas davon gesagt, dass das System einfriert.

Schöne Grüße,
Steffen
 
Und von Garbage Collection habe ich auch nicht gesprochen. :)

Wenn realer Speicher knapp wird, muss virtueller her - und das geschieht mittels Swapping (sofern ein entsprechender Swap-Space eingerichtet ist).

Das führt aber jetzt zu weit. Ich denke, wir langweilen die Nicht-Programmierer. Die wichtigen Infos stehen ja alle oben. Ich werde das bei Gelegenheit vielleicht auch noch im Presonus-Forum einstellen, aber jetzt muss ich erst mal relaxen.

Schöne Grüße,
Steffen
 
Speichermangel (also ein Memory Leak in Studio One und/oder Melodyne) kann kaum die Ursache für das Einfrieren gewesen sein
Hm...
 
@Einfach:
Noch ein Hinweis: Ich habe mit keiner anderen Software Probleme (bei Cubase, meiner Haupt-DAW, mal vom altbekannten Pool-Bug abgesehen), und ich nutze den Rechner tagtäglich intensiv - sowohl, was die Speicherauslastung angeht, als auch hinsichtlich der CPU-Belastung.

Ich bin ja selbst Entwickler der alten Schule und kenne mich bestens mit den von Dir angeführten Themen aus, die aber leider gar nichts mit dem von mir Gesagten zu tun haben. Außerdem weiß ich von einigen anderen Anwendern, dass sie exakt dieselben Probleme haben - einer hat es mir vorhin noch via PM bestätigt, und hier im Thread wurde das ebenfalls erwähnt.

Das Fehlverhalten deutet ziemlich unmissverständlich auf einen Bug im Ressourcenmanagement hin.

Ach so, übrigens: Dass ein Audio-Programm mit großen Audio-Dateien nicht umgehen kann, ist ein Bug! Die entsprechende Verwaltung obliegt dem Programm, nicht dem Anwender. Es kann nicht sein, dass ich gezwungen bin, eine Bass-Spur in kleinen Häppchen zu bearbeiten, weil das Bearbeitungsprogramm nicht ordentlich mit den Ressourcen umgeht. Exakt dieses Zerteilen in Häppchen kann und muss das Programm für mich intern tun, ohne dass ich davon etwas mitbekomme. Genauso, wie es z.B. Betriebssysteme oder gute Texteditoren auch tun. Mit sinnvoller Speicherverwaltung bekommt man es als Entwickler in fast jeder größeren Software zu tun, und das ist keine Magie.

Schöne Grüße,
Steffen
 
Es wäre so einfach, meinen Startbeitrag zu lesen und zu verstehen, wenn man denn nur wollte:

Da es vor einiger Zeit geheißen hat, die Probleme im Zusammenspiel von S1 mit Melodyne seien gelöst, weise ich sicherheitshalber mal darauf hin, dass dem nicht so ist. Hier ist also noch Bugfixing erforderlich.

Gestern habe ich längere Zeit mit Studio One daran gearbeitet, eine Bass-Spur nach Erkennung der Transienten an einer Schlagzeugspur auszurichten (manuell, Transiente für Transient). Dabei ist mir Studio One insgesamt drei Mal eingefroren und musste per Task Manager abgeschossen werden. Da ich alle paar Sekunden speichere, war die verlorene Arbeit jeweils überschaubar, aber lästig und zeitraubend bleibt es allemal.

Ich habe Studio One v2.0.6.18491, 64-Bit auf einem Windows-7-System (i5, 16 GB RAM) im Einsatz, das nur für Musikproduktion verwendet wird. Bei der verwendeten Melodyne-Version handelt es sich um Melodyne Editor 2.1.0. Ich nutze den ARA-Modus.

Ein Muster, dass eindeutig zum Absturz führt, habe ich bislang nicht erkennen können. Vielleicht liegt es daran, dass ich extrem schnell arbeite, aber eigentlich kann ich mir das nicht wirklich vorstellen.

Schöne Grüße,
Steffen
 
Danke stoman, dass du mich auf meine Arbeit hinweist. (finst das nicht auch etwas... naja?)
Ich hoffe auch, du weisst, dass DAS hier nicht dazu gehört.

Denn wenn ich als "Auch-Anwender" sage, dass es auf allen meinen Systemen läuft, dann vermute ich natürlich zu erstmal das betreffende System! Um zum richtigen Support zu kommen, habe ich Adressen hier bereits verlinkt. Viel Erfolg dort!

Ich habe hier auch niemanden abgestempelt, aber so wie du mit meiner Wortwahl nicht ganz einverstanden scheinst, so möchte ich auch umgekehrt darauf hinweisen, dass dein Ausdruck im allerersten Posting ... wie nannte ich das..... "unfair" ist. Manchmal denke ich, die Herangehens- und Denkweise der User ist irgendwie komplett falsch herum.

Anstatt so zu arbeiten, wie es möglich ist, wird so gearbeitet, wie es (nur bei Ihnen!) nicht geht.

Wie ich JETZT erst in letzten Posting erfuhr passiert da etwas mit einem Audio-Event, dass bereits mit Melodne behandelt wurde, und DANNACH Transientenerkennung durchgeführt wurde, die aber nicht zufriedenstllend war, dann einzeln Marker gesetzt wurden, und dabei ist er abgeschmiert?

Ich sehe da jetzt schon mindestens 2 mögliche Stolperstellen. Versuch doch mal bitte Folgendes:
Sobald du alles vermelodyned hast, STRG+B und bounce die fertige Bearbeitung. Dann hast du ein neues frisches und "sauberes" Audiofile. Und damit sollte eiiiiiigentlich dann auch deine Punkt-für-Punkt Transientenbearbeitung funktionieren.

Ich hoffe, der Vorschlag hilft dir nun.
Ari
 
einige kleine "einfache" Kommentare:

ein Einfrieren hat leider sehr, sehr oft seine Ursache im Hauptspeicher himself.
Wenn du unter Windows unterwegs bist äussert sich ein zerschossener Speicherriegel üblicherweise durch sporadische Bluescreens, Anwendungsabstürze, und wenn du häufig was installierst auch gern mal als CRC-Error beim Prüfen von Checksums...ein Einfrieren ist eher Ausnahme. Beim Mac kann ich's mangels Erfahrung nicht beurteilen.

Ich werd spasseshalber mal über Nacht memtest laufen lassen.

Auch der Hinweis, dass kein Dump geschrieben wurde, zeigt schon, dass das OS nicht weiterarbeiten konnte.
Grosser Käse, wenn ich nicht threadsicher unterwegs bin, wartet z.b. irgendwann der Main-Thread auf einen anderen Sub-Thread, obwohl der schon lang abgeschlossen ist. Der Main-Thread kann dann genüsslich 100% CPU zapfen, oder verzögert sein, sodass auch die CPU-Auslastung niedrig ist. Einziges Symptom in letzterem Fall ist, dass, der Hauptthread hängt und keine Eingaben zulässt, weil er noch auf was anderes wartet. Das ist per se kein Absturz und provoziert in aller Regel auch erstmal keine Reaktion des OS. Das ist nur EINE mögliche Erklärungsvariante.

Und nein, unter Win7 oder OSX führt eine Endlosschleife nicht zum völligen Einfrieren des Rechners, er wird nur uuuuunheimlich zäh.
System friert auch bei mir nicht ein. Die Anwendung hängt, keine Eingabe mehr möglich - von Speicherleck sehe ich ehrlich gesagt auch nicht viel. Auch Windows hat in der Ereignisanzeige nichts Verdächtiges. Ein klassischer "Application Hang" aufgeführt mit Startzeit, Endzeit und Prozess-ID für S1. Völlig nichtssagend.
 

Ähnliche Themen

R
Antworten
23
Aufrufe
3K
R-Kelly
R
twinnpeaks
  • Artikel
Testberichte Test: Bitwig Studio
Antworten
2
Aufrufe
34K
twinnpeaks
twinnpeaks
Can
Antworten
2
Aufrufe
21K
ahs
A
Antworten
28
Aufrufe
35K
organix
organix
OldWise
Antworten
21
Aufrufe
75K
hopoh
hopoh

Oft gelesene Themen

Zurück
Oben