CPU-Last bei geöffneten Kanälen im Mixer

• May 8, 2019 - 03:14

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

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 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 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 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 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 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

Do you still have an unanswered question? Please log in first to post your question.