1
123456789876543ggg
Guest
Super, danke. Koennen gerne ein Projekt vergleichen. Ich bastel morgen mal was.
Psychotronic
||||||||||
Psychotronic
||||||||||
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.
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:
recliq
¯\_(ツ)_/¯
, das wusste ich auch noch nicht, stimme dir aber 100% zu, dass das ne doofe Idee ist. Da wundert die Speicherhungrigkeit wirklich nicht...
Psychotronic
||||||||||
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.
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.
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.
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.
Martin Kraken
Anfänger
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.
Psychotronic
||||||||||
Im Consumer Bereich stimmt das so. Im Pro / Server Bereich wird mit RAM in der Cloud verkaufen ganz viel Geld gemacht,
Psychotronic
||||||||||
Hier nur damit man das mal gesehen hat:
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.
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.
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.
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.
Martin Kraken
Anfänger
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.
Psychotronic
||||||||||
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.
Ich geh da mal lieber mit dem Hund.
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.
Ich geh da mal lieber mit dem Hund.
Psychotronic
||||||||||
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.
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.
Psychotronic
||||||||||
Psychotronic
||||||||||
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.
1
123456789876543ggg
Guest
Das ist der Engine Log:
Pastebin Online - AppDevTools
Pastes text or code for online public viewing via a share link with syntax highlighting and an optional expiration period. Supports over 170 programming languages.
Und er der Studio Log:
Pastebin Online - AppDevTools
Pastes text or code for online public viewing via a share link with syntax highlighting and an optional expiration period. Supports over 170 programming languages.
Psychotronic
||||||||||
1
123456789876543ggg
Guest
Komisch. Ich hab's übers terminal gestartet (habe Bitwig noch nie regulär installiert). Werde es nochmal testen, danke?
1
123456789876543ggg
Guest
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.BitwigStudioMainPsychotronic
||||||||||
Also auch 3GB. Das ist der Max Heap. Wieso kann das Teil bei dir dann 8GB allokieren und in den swap laufen?
1
123456789876543ggg
Guest
Swappines hab ich auf 10 stehen. Er fängt ca. bei 6 GB mit swappen an.
Martin Kraken
Anfänger
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.
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.
Martin Kraken
Anfänger
recliq
¯\_(ツ)_/¯
Na dann bist du ja auf der sicheren Seite...Krass, ich weiß schon warum ich meine PCs selber baue
1
123456789876543ggg
Guest
Die perfekte Kiste
www.magic-computer.de
Ich ruf da morgenn mal an
Magic Computer GmbH
Günstige IT und Elektronik: PC, Computer, Hardware, Software. IT-Service und Reparatur in der Region Karlsruhe. Bestpreise bei Office, Gaming, Enterprise.
www.magic-computer.de
Ich ruf da morgenn mal an
Martin Kraken
Anfänger
Die perfekte Kiste
Magic Computer GmbH
Günstige IT und Elektronik: PC, Computer, Hardware, Software. IT-Service und Reparatur in der Region Karlsruhe. Bestpreise bei Office, Gaming, Enterprise.
Ich ruf da morgenn mal an
Du musst Scherze kennzeichnen.
1
123456789876543ggg
Guest
Wieso?
News
-
News Next-Generation MIDI Controller kommen - eine ganze Ladung- Gestartet von Moogulator
- Antworten: 1
-
2026-01-18 Dortmund - Next Level Ausstellung - läuft noch.
- Gestartet von Moogulator
- Antworten: 2
-
-
News Konzertbericht - Assfalt + Tigerjunge - Düsseldorf, 5.12.2025
- Gestartet von Moogulator
- Antworten: 0
-
-
News Sounddesign und Auswahl - Studiomöbel und Aufstellung - 2 Themen im SequencerTalk 261 - live 20:30
- Gestartet von Moogulator
- Antworten: 1
-
News Waldorf Protein - Talk mit Rolf Wöhrmann über eine neue Synthesizer-Serie
- Gestartet von Moogulator
- Antworten: 0