Board am Arsch? Ich dreh durch...

Also ich hab hier in meinem Bitwig alle Content Packs rausgenommen, auch die Basics so dass es irgendwie schon sagt, ey mach das nicht, da geht nix mehr. Ich kann mal morgen auf den RAM schauen. Vielleicht gibt das Aufschlüsse.
 
Spar dir den Demotrack.

Die DAW braucht ohne Packs beim Hochfahren 3GB und nordet sich nach der Garbage Collection sobald man was geöffnet hat irgendwann auf die Größe dessen ein was man da geladen hatte, bei mir was das mit zwei Spuren und 3 VSTs bei so 1GB.

Wer sich fragt warum das so ist, sollte im Taskmanager mal genau anschauen was da gestartet wurde. In dem Commando steht .jar

Bitwig läuft auf der java virtual machine, das konsumiert RAM zum Frühstück. Ich bin selbst ganz lange in der Industrie, auf die Idee ne DAW zu schreiben die auf der jvm läuft, würde mir echt nicht einfallen.

Also versteh mich nicht falsch. Das kann man alles machen, nur ernsthaft, dann schraubt dir max RAM in die Kiste die das fährt, die Cloud Systeme meiner Kunden sind auch alle RAM maxxed meine dev Systeme auch. Das macht sonst absolut keinen Spass, vermutlich ist mir das deshalb auch noch nicht aufgefallen, denn ich arbeite nur mit Kisten die den maximalen RAM Ausbau haben. CPU Power ist da gar nicht so krass wichtig, zumindest wenn deine Programme über parallel functions und Threads ordentlich verteilt sind.

Ne DAW die ordentlich Cached und auf der jvm läuft würde ich eher bei 8GB aufwärts einordnen, sobald man die wirklich benutzt.
 
Zuletzt bearbeitet:
Bitwig ist Java :rofl: , das wusste ich auch noch nicht, stimme dir aber 100% zu, dass das ne doofe Idee ist. Da wundert die Speicherhungrigkeit wirklich nicht...
Wenn ich es nicht besser wüsste würde ich vermuten das Java von RAM Herstellern erdacht wurde.
 
Nicht unbedingt java, das kann auch scala oder irgendwas anderes aus dem Universum sein, aber ja, das ist definitiv RAM hungrig. CPU ist allerdings andersherum zu sehen. Java hat in der letzten Dekade ganz viel Zeug eingebaut bekommen was es für Devs extrem einfach macht Software auf CPU Cores zu verteilen. Man tauscht quasi das gegen RAM Verbrauch. Daher sind auch Dröwlf Trollionen online Dienste in Java gebaut und ganz viel im Cloud Bereich. Core Verteilung ist absolut essentiell bei Multi User Anwendungen, also irgendwas wo die Usermenge zeitgleich > 100 ist.

Als DAW Dev kannste jetzt natürlich sagen, hey die Core Verteilung geht damit super einfach, damit können wir selbst Berechnungen einfach funktional aufbrechen und auf Cores über parallel functions verteilen und map/reduce zeug bauen. Das macht schon so halb Sinn, aber das kauft man sich halt über RAM Verbrauch ein.

Spekulation: Sind die Devs damals von Ableton weg weil sie ihr heil in der flucht ins java land suchten? Sehr Unterhaltsam. :fressen:

P.S. Cloud geht natürlich auch in schmal mit golang und ähnlichem, nur falls das wer liest, spar dir den Argumentationsaufwand. Alles bekannt, alles gut.
 
Naja RAM kostet ja nix mehr. 64 GB DDR 5 für 200 Euro und DDR4 für 160 Euro. Selbst 128 GB sind jetzt keine riesige Investition mehr. Wenn man clever ist, bekommt man quasi für fast jeden Anwendungsbereich ein Top PC unter 700 Euro. Ob Gameing, Videoediting oder Musik, ein PC mit ausreichend Power ist nicht wirklich teuer.
 
Naja RAM kostet ja nix mehr. 64 GB DDR 5 für 200 Euro und DDR4 für 160 Euro. Selbst 128 GB sind jetzt keine riesige Investition mehr. Wenn man clever ist, bekommt man quasi für fast jeden Anwendungsbereich ein Top PC unter 700 Euro. Ob Gameing, Videoediting oder Musik, ein PC mit ausreichend Power ist nicht wirklich teuer.

Im Consumer Bereich stimmt das so. Im Pro / Server Bereich wird mit RAM in der Cloud verkaufen ganz viel Geld gemacht,
 
Hier nur damit man das mal gesehen hat:

bitwig.png

Alles was *.so ist lief durch nen C/C++ Compiler. Die Audio und Plugin Engine auch, da hab ich auch grad mal ein ldd drauf ausgeführt. (Schauen wogegen das gelinkt ist)

Bitwig als Programm selbst ist ne *.jar Also ein Java Archive.

bitwig2.png

Ne eigene Java Runtime ist auch installiert, man muss also kein Java vorher auf dem Rechner haben.

Das Haupt Jar File ist obfuscated, also mit nem Prozess so geshreddert das man den Code schlecht Reverse Engineeren kann, ich sehe aber nach Durchsicht der Packages nix was direkt zumindest nach Scala oder ähnlichem riechen würde. Vermutlich ist es tatsächlich einfach direkt in Java geschrieben.
 
Wenn RAM so günstig ist, dann ist es halt auch egal ob das Ding 8 Gig am Anfang voll macht und damit dann einfach schneller im Betrieb ist. Irgendwann muss man die Gegenheiten, dass man jetzt mehr RAM hat auch nutzen. Da sich quasi jeder jetzt für sehr kleines Geld 32 GB leisten kann, werden immer mehr Prg. das auch nutzen. Fortschritt und so.
 
Ja, allerdings hat das bei größeren RAM Mengen einen Seiteneffekt, den man als nicht Entwickler nicht wissen kann und auch noch nicht mal alle Entwickler im Java Bereich wissen und dort ist der Knackpunkt.

Ich schrieb Eingangs, dass ich Bitwig hochgefahren hatte mit 3GB RAM und es sich danach auf 1GB RAM entspannte, das lässt mich aufhorchen.

Grundsätzlich ist es in Java so, das alles was man erzeugt an Variablen, Datenstrukturen und Funktionen erstmal RAM frisst, das ist noch nicht das Problem. Wichtig ist eher das der Code so gestaltet ist das sich die Dinge nach der Ausführung selbiger wieder schnell wegräumen lassen. In Java geht das leider so das man den Code in einem gewissen Stil schreiben sollte, dann landet man in der schnellen Garbage Collection oder man gewisse Anteile so schreibt, dass sie erstmal gar nicht weggeräumt werden. Wenn man das nicht sauber macht, dann rödelt die Garbage Collection die ganze Zeit im Hintergrund rum und blockiert das restliche System. Je mehr RAM das Programm verwendet um so deutlicher treten diese Verzögerungen zu tage wenn nicht sauber gearbeitet wurde.

Man kann das mit nem Profiler auseinander nehmen und sich bei Bitwig mal anschauen. Dann sollte man aber den normalen Code und nicht den geshredderten nehmen und ehrlich gesagt, mache ich sowas dann nur als Beratungsleistung zu meinem normalen Stundensatz. :connect:

Ich geh da mal lieber mit dem Hund.
 
Hmmmm, man könnte natürlich mit nem Hack die jvm von Bitwig wrappen und ne java environment variable injecten mit der man die mindest allocation vom RAM konfiguriert und das auf was stellt das > dem RAM Verbrauch eines richtig großen Setups / Tracks in Bitwig ist, dann fährt der hoch und krallt sich den RAM und dann wars dann mit RAM dynamisch freigeben. Dann merkt man die Garbage collection weniger. Sprich es hat dann im Stand angenommen 6GB RAM weil man das so will.

Wenn man jetzt irgendwie fies viel RAM hat lohnt sich das möglicherweise, das der bei großen Änderungen nicht mehr direkt den RAM freigeben muss.

Ich schau mal ob das möglich ist. Die jvm hier ist auf jeden irgendwas normal aktuelles.
 
Danke das erklärt es dann natürlich. Was ich nicht verstehe: Bitwig fährt hoch, RAM geht auf >8GB und es wird geswappt. Warum braucht Bitwig am Anfang so viel RAM und warum wird der nicht sofort wieder freigegeben?

Hattest du das mit den kleinen Lenovos getestet?
 
RAM geht auf >8GB und es wird geswappt.

kannst du bitwig mal von commandline starten, das command ist bitwig-studio die binary liegt im haupt ordner der software. Dann kopier mir mal die die ersten paar zeilen des logs bis: "Using log directory /home/marko/.BitwigStudio/log"

Dort printed die Software mit welchem Command dein Bitwig startet, dort stehen werte zur Memory Config drin, schauen wir mal was da bei dir steht.
 
kannst du bitwig mal von commandline starten, das command ist bitwig-studio die binary liegt im haupt ordner der software. Dann kopier mir mal die die ersten paar zeilen des logs bis: "Using log directory /home/marko/.BitwigStudio/log"

Dort printed die Software mit welchem Command dein Bitwig startet, dort stehen werte zur Memory Config drin, schauen wir mal was da bei dir steht.

Das ist der Engine Log:


Und er der Studio Log:

 
Hmmm, das steht bei dir in beiden logs nicht drin. Was ich suche ist das hier:

bitwig3.png
 
Hmmm, das steht bei dir in beiden logs nicht drin. Was ich suche ist das hier:

Anhang anzeigen 203255
Ich bin ja auch ein Trottel. Das steht nur im terminal output, nicht im Logfile:

Code:
/home/fox/music_software/opt/bitwig-studio/bin/libs.jar:/home/fox/music_software/opt/bitwig-studio/bin/lwjgl.jar -Dorg.sqlite.lib.path=/home/fox/music_software/opt/bitwig-studio/lib/bitwig-studio -XX:+UseZGC -Xms300m -Xmx3g -Djava.io.tmpdir=/tmp/bitwig-fox -DinstallationRoot=/home/fox/music_software/opt/bitwig-studio -DsplashPid=12502 -Djava.awt.headless=true -XX:ErrorFile=/home/fox/.BitwigStudio/bitwig-studio-jvm-crash.log com.bitwig.flt.app.BitwigStudioMain
 
Ich bin ja auch ein Trottel. Das steht nur im terminal output, nicht im Logfile:

Code:
/home/fox/music_software/opt/bitwig-studio/bin/libs.jar:/home/fox/music_software/opt/bitwig-studio/bin/lwjgl.jar -Dorg.sqlite.lib.path=/home/fox/music_software/opt/bitwig-studio/lib/bitwig-studio -XX:+UseZGC -Xms300m -Xmx3g -Djava.io.tmpdir=/tmp/bitwig-fox -DinstallationRoot=/home/fox/music_software/opt/bitwig-studio -DsplashPid=12502 -Djava.awt.headless=true -XX:ErrorFile=/home/fox/.BitwigStudio/bitwig-studio-jvm-crash.log com.bitwig.flt.app.BitwigStudioMain

Also auch 3GB. Das ist der Max Heap. Wieso kann das Teil bei dir dann 8GB allokieren und in den swap laufen?
 
Habe gerade für jemand der kein Geld hat ein PC-Konfig für ein Audio PC gemacht. Vielleicht auch ein build für dich?

ASRock Deskmini x300 = 150 Euro
AMD 5600g = 100 Euro
32 GB RAM SO Dimm DDR4 3200 = 60 Euro
1 TB M2 SSD = 65 Euro

Gesamt 375 Euro. Mit 5700g + 60 Euro.

Das Ding reicht völlig für jede normale Audioproduktion, wenn man nicht gerade Orchesterfilmmusik macht. Oder 100 Spuren mit Effekten vollknallt.
 
Die perfekte Kiste

Ich ruf da morgenn mal an
 
13600K
DDR 5
32 GB
BeQuite Netzteil
Marken SSD
Asus Board, kein Problem mit Linux
Rest auch gut.

Finde den Preis ziemlich fair.
 
Zurück
Oben