Piano roll editor: adjustment issues, including crash

• Dec 2, 2018 - 12:05
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
needs info
Regression
No
Workaround
No
Project
Tags

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4095, revision: 5859662

Open the attached score.

  1. Open the Piano Roll Editor and click on the first bass note—D3;
  2. Click on the control point of the Length marker and move it down.

Expected result: The marker should move smoothly up or down.
Actual result: The marker gets stuck, requiring release and re-engagement of the mouse button (which can be tricky).

  1. Press the UNDO icon.

Expected result: Immediate UNDO of adjustment.
Actual result: UNDO seems hit or miss. Sometimes it responds slowly, other times not at all.

  1. Reload the score (without saving), open the Piano Roll Editor and click on the first bass note—D3;
  2. Change the markers to "Velocity Offset";
  3. Click on the marker and move it up or down.

Result: CRASH. The same happens with "Velocity Absolute."

  1. Reload the score (without saving), open the Piano Roll Editor and click on the first bass note—D3;
  2. Change the markers to "On Time";
  3. Try adjusting the marker.

Result: Difficult, if not impossible to adjust.

Attachment Size
piano_roll_editor.mscz 7.44 KB

Comments

Priority P1 - High

Confirmed. To the point one, it moves smoothly if you follow the vertical line of the Length marker. I suspect all other issues relate to this since the mouse events are processed incorrectly.

Also, I see incorrect updating of the piano roll when switching between scores.

The times that Musescore does not crash when adjusting velocity levels in the PRE, in my own scores, the marker gets stuck like the length markers--very awkward.

Edit: Actually, Musescore Beta (December 14) crashes every time I try to adjust the velocity markers. Tested on OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4516, revision: 59a11cd

For points 1 and 2, the PRE is operating as I designed it. The idea behind the current design is to make it easy to adjust multiple note levels at once with a single swipe of the mouse. This way you can select several notes with the mouse and set their values in the levels editor with a single mouse swipe from left to right. This can make it easier, for example, to crescendo over a run of 16th notes. This does make treating each bar as if it is a slider more difficult. Maybe we can discuss design ideas.

I'm not getting the crash from adjusting the velocity after reloading. What do you mean by 'reload'? Just going to File/Open and selecting the same score again?

The undo issue is due to no update() being issued when the undo button is pressed. I'll have to hunt down the undo routine and see if I can get that to refresh the PRE.

The crash is reproducible for sure by following the exact steps from @geetar's scenario. 'Reload' means "close the score without saving, open the score again" here.

Tried it again, following instructions carefully. I'm not seeing a crash. What's the stack track of the crash? Also, maybe the changes I've made so far have inadvertently fixed the crash?

In reply to by blackears

I am a mere mortal layperson. How do I access the stack trace? Running Debugview.exe and then double clicking debugMode.bat, which launches "Musescore.exe -d" from a command line) in the Musescore 3's "special folder", doesn't turn up any specific info on your PRE and doesn't report any thing when Musescore crashes. This is the last line [4176] no drumset (Debug | Print )n reported, which I don't think is related, before Musescore crashes. I think part of the problem is that my nightly build is not a debug build. According to https://musescore.org/en/node/271213 , by itself Musescore.exe -d doesn't do anything unless the version of Musescore is a debug build, no? If so where do I download the debug build for Windows?

In reply to by Marc Sabatella

I would be interested to see if the current nightly build crashes for Geetar, who is the one originally submitted this issue, and Anatoly-os, who initially confirmed it. I am assuming Blackbear and Marc that you are testing this on Windows systems?

It appears that I have to build my own debug version of Musescore in order to get detailed log output (https://musescore.org/en/handbook/developers-handbook/compilation), which is something I don't want to attempt right now. It would be great if the debug version was automatically built and included among the standard nightly builds.

In reply to by Sambaji

Sorry, I was presuming everyone commenting here was involved with the programming. You'd need to be running MuseScore with a debugger tool to see the stack trace. The stack trace gives you more information about what is happening in memory at the time of the crash.

That said, I'm running this on Windows 10 and not seeing the crash. I'd need to be able to produce it myself to be able to work on this.

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4648, revision: 40a27b9

Again, on steps 4-6, the marker refuses to move and the program crashes.