CPU-Last bei geöffneten Kanälen im Mixer
Hallo,
mir ist aufgefallen, das in der Version 3.0.5 bei Instrumenten wie Violine, Bassgitarre, ..., die mehrere Kanalzüge haben, die CPU-Last massiv ansteigt, wenn diese ausgeklappt sind.
Kann das jemand nachvollziehen?
Ich verwende Linux und habe Musescore aus einem Repo installiert. Mit dem Appimage habe ich es noch nicht getestet.
Wäre interessant, ob es sich nur um ein Problem bei mir handelt, oder nur in der Linuxversion oder generell ein kleiner Fehler drin ist.
Ein kleines Video, wo man das 'gut' sehen kann, liegt auf Youtube https://youtu.be/RIG3UsD-wUk
Grüße
Tux
Comments
Hallo tuxan,
kann ich bestätigen. Ich habe Linux Mint 19 als AppImage.
Gruß, Pentatonus
Inzwischen konnte ich es unter Windows 10 testen.
Der gleiche Effekt.
Tja, wenn ich Englisch könnte, würde ich einen Bugreport (Low/Medium) schreiben.
(Ist garantiert nur eine Kleinigkeit. Ich könnte fast wetten, das ein 'wait 1' am Ende der Prozedur reicht).
Finde zur Zeit keinen Spielraum, dies zu testen. Du kannst aber einen Bugreport auf deutsch verfassen, irgendjemand wird es schon ins Englische übertragen. Wichtig sind dabei die Schritte aufzuschreiben, damit es reproduzierbar ist bzw. zum Verdeutlichen "Screenshots" hinzuzufügen (zum Beispiel die CPU-Verteilung im Taskmanager vor und nach Ausklappen) oder sein verlinktes Video. Natürlich auch immer verwendete MuseScore-Version und Betriebssystem angeben.
In reply to Finde zu Zeit keinen… by kuwitt
Ok, dann versuche ich es mal. Da Screenshot da nicht so die Aussagekraft hat, habe ich dafür ein neues, hoffentlich besser darstellendes Video aufgenommen.
Reported version: 3.0
Priority: P3 - Low -- (evtl. auf Grund von Singel- oder Dual-CPUs: P2 - Medium)
Type: Performance (evtl. UI - was ich vermute)
Frequency: (?)
Severity: (?)
Reproducibility: Always
Status: open issue
Regression: (?)
Workaround: No
Project: MuseScore
CPU-Last steigt stark bei ausgeklappten Kanälen im Mixer an.
OS: getestet Linux (Opensuse Leap 15.0 [Repo]), Windows 10
Bestätigt: Linux Mint 19 als AppImage
Reproduzierbarkeit:
- Instrument mit mehreren Kanälen hinzufügen (z.B. Violine, E-Bass, ...)
- Mixer anzeigen
- Kanäle ausklappen, etwas warten, wieder einklappen (dabei CPU-Last beobachten)
Demo-Video (2 Minuten) unter: https://youtu.be/1kh4ys8-9Ik
Versuch mit Übersetzungsprogramm (keine Ahnung, ob das verständlich ist):
CPU load increases strongly when channels in the mixer are unfolded.
OS: tested Linux (Opensuse Leap 15.0 [Repo]), Windows 10
Affirmative: Linux Mint 19 as AppImage
Reproducibility:
- Add instrument with several channels (e.g. violin, electric bass, ...)
- Show mixer
- Fold out channels, wait a bit, fold in again (observe CPU load)
Demo video (2 minutes) below: https://youtu.be/1kh4ys8-9Ik
Grüße
Tux
In reply to Ok, dann versuche ich es mal… by tuxan
OK, jetzt im Issue Tracker als #289082: High CPU load with Mixer and opened channels
In reply to OK, jetzt im Issue Tracker… by Jojo-Schmitz
Danke
In reply to OK, jetzt im Issue Tracker… by Jojo-Schmitz
Hallo,
wie ich gerade entdeckt habe, war das schon mal Thema und sollte gefixt sein.
--(27.11.18)--> https://musescore.org/en/node/278897
Habe gerade 3.1 beta ausprobiert und da steigt auch die CPU-Last extrem an.
Ich schreibe das, weil ich befürchte, wenn das im Tracker gelesen wird, das Problem bereits als erledigt betrachtet wird.
Grüße
Tux
In reply to Hallo, wie ich gerade… by tuxan
#278897: High CPU load while the mixer is open solllte in der Tat gefixt sein, evtl. ist es mit dem neuen Mixer zurückgekommen
In reply to #278897: High CPU load while… by Jojo-Schmitz
Hallo,
Der Fix dafür wurde am 27.11.18 eingebracht. In welcher Version er da zum tragen kam, weiß ich nicht.
Die Version 3.0.5 wurde am 12.03.19 freigegeben. Da sollte er doch integriert sein. Nur ist die CPU-Last nach aufklappen immer noch extrem hoch. Genaugenommen 100% für den dafür aktiven CPU-Kern, worauf 60-80% auf Musescore direkt fallen, der Rest auf Systemressourcen, die Musescore dafür beansprucht.
Ich habe es eben nochmal getestet und der Bug besteht nach wie vor.
Repo:
OS: openSUSE Leap 15.0, Arch.: x86_64, MuseScore version (64-bit): 3.0.5., revision: 58dd23d
AppImage:
OS: openSUSE Leap 15.0, Arch.: x86_64, MuseScore version (64-bit): 3.1.0., revision: 1982daf
Windows boote ich deswegen nicht erst. Da ist Version 3.0.5 installiert und wurde von mir bereits getestet und da besteht der Bug auch.
Mich beschleicht das Gefühl, das es von den Programmierern ignoriert wird, weil im Hinterkopf - wurde gefixt, der verwendet wohl ungefixte Version - hängt. Das Schlußfolgere ich daraus, das ein Eintrag vom Februar (https://musescore.org/en/node/284339 - Version 3.0.2) diesen Jahres (also knapp 3 Monate nach dem Fix) unbeachtet blieb.
Nachdem ich das eigenwillige Verhalten der Regler (siehe: https://musescore.org/de/node/289155) entdeckt habe, glaube ich nicht mehr, das es nur an einer Kleinigkeit liegt, wie ich ursprünglich gedacht habe. Ich vermute hier eher einen strukturellen Fehler, der vielleicht zu einer Rekursion führt, die die CPU-Last dann hervorruft. Der eingebrachte Patch verringert dabei nur etwas die Symptome, das Problem bleibt aber bestehen.
Auffälligkeiten, die auf einen strukturellen Fehler hinweisen:
Bei aufgeklappten Kanal
- Mit bewegen des ersten Subfaders bewegt sich auch der Mainfader des Instruments, während die anderen Subfader keine Auswirkung auf den Mainfader des Instruments haben
- Änderungen des Mainfaders setzt alle Subfader auf den Wert des Mainfaders
In Version 2 waren die jetzigen Subfaders des Instruments als Hauptfader ausgeführt. Es gab keinen übergeordneten Fader.
In Version 3 wurde ein übergeordneter Fader eingeführt, der allerdings mit einem Subfader gekoppelt zu sein scheint. ...
Daraus schließe ich, daß das Problem nicht in der GUI liegt (worauf sich der Patch ja bezieht), sondern in der Handhabung der Lautstärkeroutinen (oder was auch immer dahintersteht).
Mein Lösungsvorschlag wäre:
1. Den Mainfader als Fader entfernen und nur als Aufklappeinheit auszuführen (wäre wie bei Version 2, nur mit aus-, einblenden derFader
Wenn das dann problemlos funktioniert
2. Einen Mainregler einführen, der nur incrementell Änderungswerte an alle Subfader sendet und keinerlei Rückkopplung zu einen der Fader hat (die Stellung dieses Mainfaders ist nicht trivial umzusetzen)
So, das in Kurzform über das Problem, wie ich es sehe.
Bleibt nur die Frage, wie der/die Programmierer diesen Teiles des Programms den Gedanken erfahren und sehen.
Grüße
Tux
In reply to Hallo, Der Fix dafür wurde… by tuxan
Der Fix war in der 3.0 drin. Aber in 3.0.1 wurde am Mixer was geändert, gut möglich dass der Bug damit zurück kam.
Wurde heute kurz im Developer Chat erwähnt (von mir) und @dmitrio95 will sich das ansehen.
In reply to Der Fix war in der 3.0 drin… by Jojo-Schmitz
Wie versprochen, @dmitrio95 sieht sich #284339: Eats up all CPU while mixer is open and instrument change is expanded gerade an ;-)
In reply to Wie versprochen, @dmitrio95… by Jojo-Schmitz
Danke.
Evtl. wäre ein Zusatzhinweis für das sicherlich nicht gewollte Faderverhalten sinnvoll. Wie sagt man: Ich habs im Urin, daß das zusammenhängt. ;-) Weil die Fader falsch implementiert sind, kommt es zu Rekursionen in der GUI. Und dann enteht die Last. Oder so ähnlich.
Wir werden sehen. Bin da ganz zuversichtlich.
In reply to Hallo, Der Fix dafür wurde… by tuxan
Ggfs. dies noch mal mit vorhergehenden MS-Versionen abgleichen/eingrenzen: http://ftp.osuosl.org/pub/musescore-nightlies/linux/x86_64/?
In reply to Ggfs. dies noch mal mit… by kuwitt
Ok, gemacht.
Test AppImages:
Verwende immer Violine zum testen.
~> ./MuseScore-3.0.0-x86_64.AppImage -a alsa
- CPU-Load High, Faderproblem: ja
~> ./MuseScore-3.0.1-x86_64.AppImage -a alsa
- CPU-Load High, Faderproblem: ja
~> ./MuseScore-3.0.2-x86_64.AppImage -a alsa
- CPU-Load High, Faderproblem: ja
~> ./MuseScore-3.0.3-x86_64.AppImage -a alsa
- CPU-Load High, Faderproblem: ja
~> ./MuseScore-3.0.4-x86_64.AppImage -a alsa
- CPU-Load High, Faderproblem: ja
Die 3.0.5 und 3.1-beta habe ich schon getestet. Das Gleiche.
Weil wir gerade bei den AppImages für Linux sind.
Der Fehler in der AppRun ist noch drin.
~> ./MuseScore-3.1.0-Beta-x86_64.AppImage
/tmp/.mount_YHCLag/AppRun: Zeile 15: ldconfig: Kommando nicht gefunden.
bei Alsa witzelt er sogar noch ;-)
~> ./MuseScore-3.1.0-Beta-x86_64.AppImage -a alsa
/tmp/.mount_eyAkdy/AppRun: Zeile 15: ldconfig: Kommando nicht gefunden.
Jack does not appear to be installed. That's OK, we'll use a dummy version instead.
Klar, wenn /sbin (wo in vielen Distries ldconfig liegt) nicht in der Pfadvariablen (wie bei den meisten Distris) ist, kann das Programm auch nicht gefunden werden. Alter Programmiererfehler. Jeder, der seinen ersten cron-Job schreibt, lernt das mit großen Augen.
Da fehlt sowas hier:
PATH=/sbin:$PATH
export PATH
Grüße
Tux
In reply to Ok, gemacht. Test AppImages… by tuxan
~> rpm -qi musescore
Name : musescore
Version : 3.1.0
Release : lp150.29.1
Architecture: x86_64
In reply to Hallo, Der Fix dafür wurde… by tuxan
Hallo Tux, ich finde es gar nicht schlecht, dass der erste Sub-Regler mit dem Master gekoppelt ist. Z.B. bei Violine sind ja die Subs Arco, pizz und tremolo. Und Arco ist ja das "normale", übliche, meistgenutzte. Quasi der Master in klein ;-)
In reply to Hallo Tux, ich finde es gar… by Pentatonus
Hallo,
tja, und genau da liegt der Fehler. Korrekt wäre, wenn er die anderen Kanäle zusätzlich anzeigen würde. (Und natürlich keine Verbindung der Fader untereinander besteht.)
Da beim Aufklappen aber alle Kanäle angezeigt werden, gehe ich davon aus, das alle Kanäle unabhängig von einander geregelt werden können sollen und dessen Ausgänge in einen 'Gruppen'regler gehen sollen, wo die Summe der Kanäle geregelt werden können soll. So wie in jedem gruppenfähigen Mischpult auf und vor der Bühne.
In Version 3 besteht diesbezüglich ein Verdrahtungsfehler. Und ich vermute, daß das die Probleme verursacht. Schau Dir mal das Video an und vollziehe es nach, dann wirst Du verstehen, was ich meine.
https://www.youtube.com/watch?v=d605ftD-_XA
Grüße
Tux