Musescore 3 loses focus

• Aug 19, 2019 - 02:46

One of the most annoying "features" of Musescore are associated with editing the last measure on a page.
When the last measure on page becomes too long and does not fit on the same page - the score gets re-formatted and.... the measure being edited DISSAPEARS from view.

In a large orchestral score it takes a good while to find the measure again that was subject to editing. This disrupts creative thoughts with annoyances.

Of course reformatting is necessary, but WHY a measure that is the focus of the User and is in zoom disappears from view and needs to be found, re-zoomed etc..?

During editing the measure being edited or in focus should ALWAYS STAY ON SCREEN and not disappear suddenly without warning, even when pages are reformatted automatically.

Comments

• Aug 19, 2019 - 07:43

I agree that it's quite irritating to lose sight of the previous measure while editing, but there is a quick way round this.

"In a large orchestral score it takes a good while to find the measure again that was subject to editing"
My workaround is immediately to use the Left Arrow key to jump right back to the previous measure, while still in Note Entry mode. Then after a quick look (e.g. Was the last note entered at the correct octave?), use Right Arrow to get back to the actual business of entering more notes on the following page.

Reply

• Aug 19, 2019 - 13:29

I think I know what you mean as I have seen things like this happen, but I couldn't reproduce it just now (3.2.3), so I wonder if there are really only some specific cases where it happens. Can you attach a score and precise steps to reproduce the problem?

Meanwhile, though, the same workaround mentioned above should apply - simply press left or right to move the cursor and the view should always reposition.

Reply

• Aug 19, 2019 - 18:01

Attached is a score with 1 note in the last measure.

Try to add some accidental (#) to this note and the measure disappears from screen view.
Undo your accidental (ctrl+Z) and then change this note to triplet (ctrl+3).
The view follows the cursor to new page,

Then change your mind and undo the triplet (ctrl+Z). The measure disappears from view again.

The screen view follows the cursor for some editing operations and for others it does not. Go figure...

Attachment Size
cursor_view.mscz 13.3 KB

Reply

• Aug 19, 2019 - 18:41

I can reproduce what you are saying in normal view but not in note input. In note input, anything I do causes the view to update. In normal view, it seems at first glance that any command that adds a new note does, but changes to the current note (whether of pitch or duration) do not. So probably a call to adjustCanvasPosition() is missing from a couple of specific commands. I would encourage you to experiment a bit more to see if you can clarify it any further than that (other specific commands that don't reposition the view in particular modes) then submit an official bug report to the issue tracker with this info.

Reply

• Aug 19, 2019 - 23:41

There may be a smarter solution than chasing commands that lose the cursor from view.

Any time when line-formatting takes place (for whatever reason) there should be an update to CanvasPosition.

This fix would "catch all" : end-of-page measures, end-of-line measures (the problem of edited measure disappearing from screen occurs at end-of-line measures for zoomed score, see attached) as well as "undo" Ctrl+Z

Attachment Size
cursor_view1.mscz 13.51 KB

Reply

• Aug 20, 2019 - 02:35

It's much more complicated than that, though. For one thing, a much more common complaint is that the view jumps too much. Some people don't even want the view following the cursor after entering the last note in a measure, but also any number of other operations move the view in ways that are seen as distracting. So it's a tricky balance to maintain. Regarding undo, the additional complication is that in order to position the view we need a specific element to follow, and the element we select on undo often doesn't even exist yet. Not sure that made sense, but anyhow, the point is that in order to create behavior that seems logic and consistent, you actually need a lot of special cases, because the more generic solutions lead to excessive jumping and also crashes as we try to follow elements that don't exist because of undo/redo.

Reply

• Aug 20, 2019 - 04:25

View should follow cursor, or more precisely speaking, follow the measure where the cursor (the highlighted element) is. If some user really likes to work blindfolded, there could be a setting to disable the "view follows cursor" behavior.

I the note entry mode "N" the view follows the cursor already, which is great. But many editing commands and shortcuts that increase the length of a measure do not require "N" mode. It is logical to extend the "view follows cursor" behavior to all editing commands so that Users are not surprised by disappearing cursors, and even disappearing of the entire score...

Undo and redo commands rely on some "history" or operations being stored, so that there should be no problem referring to measure that was last accessed.
Perhaps cursor choices need to be included in this history.

I still think that any line reformatting should be followed by cursor-focus display adjustment if cursor disappears.

Reply

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