Piano roll editor: adjustment issues, including crash

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.

I'm not sure about the visibility of this issue. Regarding the On Time, see #278693: Piano Roll Editor: On time display cannot show negative values

Adjusting positions of the markers is indeed the pain. So, @blackears please take a look. Crash is confirmed as well.

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.

I've created a fix for the undo issue: https://github.com/musescore/MuseScore/pull/4428

I've also added a feature to make it easier to click and drag single values.

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?

Just tried the latest build. Still crashing in Windows when moving Velocity markers. Where is the stack track of the crash?

Meant to say stack trace. That is, what are the file names and line numbers showing the point where it crashed?

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?

I tried to reproduce using latest build but failed. I mean, dragging the markers is finicky for sure, but no crashes.

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.

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.

Besides Debugview.exe , which didn't record any relevant errors that I could see, what debug tool would you suggest?

QtCreator or Visual Studio, if you are on Windows. But you'd basically be branching the source code and compiling and running your own copy of MuseScore at that point.

The developer's handbook contains instructions for building and running, but it can be difficult to do if you're not familiar with programming: https://musescore.org/en/handbook/developers-handbook

@blackbears, I have done basic website programming and have built packages in Linux, so I am not an entire novice. I'll give the compile and debugging instructions you gave a shot and get back to you in a couple of days.

Fixed in branch master, commit 572d18b278

fix #279229 Pianoroll update issues

PRE is now updated when undo/redo command issued.
Can now click and drag single note events in PRE.

Fixed in branch master, commit 737e6d478e

Merge pull request #4428 from blackears/279229-PRE-adjustment-issues

fix #279229 Pianoroll update issues

Not completely, need to check whether the crash still happens.

@Anatoly-os, were you (or anyone else in the thread) able to reproduce the crash ever since?

If not, kindly set the status back to "fixed".
If yes, please advice if at least the undo issue was fixed in the meanwhile or if it still persists, as i'm currently assembling an Epic for Undo-related issues.

(if it's 2xyes then pls add a link by replying with [#303762], thx in advance)