MuseScore randomly jumps to beginning of score.

• Jun 6, 2022 - 02:52
Reported version
3.6
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Randomly
Status
active
Regression
No
Workaround
No
Project

While editing a score (on any page, in various keys), MuseScore randomly jumps to the beginning of the score. This happens frequently enough to make editing a score a frustrating (and sometimes error-prone) process.

Occasionally it happens while not touching the computer.

I do not yet have any correlations as to when it happens.

Platform: Windows 10 Home Edition, Build 19044.

MuseScore version: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34


Comments

Status active needs info

If it happens while not touching the computer, the obvious possibility here is that the "Home" key on your computer keyboard is defective and is intermittently engaging and disengaging. I'd recommend a can of compressed air - best to hit all keys, actually, but focus on Home as well as the cursor keys (since Fn+Up is a shortcut for Home), and if that fails, a new keyboard.

If you continue to have problems, then in order to investigate, we'd need a sample score and precise steps to reproduce the problem. It doesn't happen for others, so there must be something unique about your scores or your workflow that is triggering this. So you'd need to take notice next time it happens - which score were you on, which measure were you working on, what exactly did you press or click. Then see if you can reproduce that. Even if you aren't able to reproduce the problem right away, if it happens often, make a note of these things anyhow and hopefully eventually you'll discover a pattern.

But definitely try the compressed air first, it definitely solves a lot of problems like this.

In reply to by Marc Sabatella

Thanks for the prompt reply, Marc.

Sticking keys did occur to me. And it is a good idea to air-clean the keys anyway.

But this problem is not occurring in word processors, web pages or other software.

It does appear to be score-specific (I checked other scores). The score is attached.

Note that, per my settings, there is a hidden staff and hidden invisible elements.

I will continue to look into possible hardware or Windows problems. I have not ruled out that possibility. I will let you know as soon as I uncover any.

Some of the keystrokes that I noticed that intermittently cause the problem are:
Clicking ctrl S to save a file (moderately consistent).
Sometimes just pressing the shift key.
Sometimes clicking on a spot on a bending chart.
Sometimes using two fingers on the glide-pad to drag the score within the editor.
Others situations that I do not recall.

I should add that, like two similar problems that others have reported (when they perform a specific action, and the score homes to the top), whatever action that I am performing completes successfully, in addition to homing to the top of the score.

Attachment Size
Rhapsody_in_Blue Intro Ver 10.9-Bb.mscz 87.34 KB

Aha, it's simple indeed to reproduce with this specific score. For instance, navigate to the end of the score, then save - problem occurs. Pretty much any save operation resets the view to the top of score. And that also explains why it sometimes appears to happen randomly - that's autosave kicking in every two minutes.

I did a little trial and error, and found some anomalies. For one thing, the score has multimeasure rests turned on (as you can see if you try deleting contents of several measures in a row). If you take the original score and do nothing but press "M" to disable the multimeasure rests, the problem goes away. It comes back if you re-enable them, though. So something is wrong in how some elements are linked to the the contents of the multimeasure rests. Also, if I make the flute visible, then delete the graphic with the CC image, then make the flute invsiible again, it works with or without multimeasure rests. So it could be that specifically.

FWIW, it doesn't seem to happen in current builds of MuseScore 4. So perhaps it was a bug already fixed. I'll leave this open in case there are other examples yet to be discovered where MuseScore 4 would also be affected.