Improve algorithm for determining start measure for note input

• Oct 24, 2019 - 18:44
Reported version
3.2
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

When you enter note input mode, we try to find a good place to start based on the current selection.

If nothing is selected, we take the first currently-displayed measure. I propose checking first to see what the last-selected CR is and using that instead, if it is in view (last selected CR is something only now available to us in 3.3).

If a note or rest is selected, we start there, no changes proposed.

If something other than a note or rest is selected, we look up the parent chain until we find a measure and start there. But, this fails if something is selected that is not a descendent of measure - that includes spanners, beams, and frames. I propose we simplfy this code to just use tick of the element (something that wasn't always available when this code was originally written).

Comments

• Oct 24, 2019 - 19:35

https://github.com/musescore/MuseScore/pull/5418

Sorry, CR = ChordRest, the internal term for the C++ base class for both chords and rests.

In general, we should already be doing a pretty job of finding a good place to enter things, it's really only a few specific cases where we don't exactly what one would want based on the selection. The main cases where the would be a major jump are the cases where you selected something we can't find a measure for (hairpin or other line, beam, or frame), and that's fixed by this.

One thing that isn't changed and conceivably could be but I question whether it should be is if you do have something selected but it is not currently in view. In that case, we honor your selection and reposition the view there. We could choose to ignore selections not currently in view, but I'm not convinced that's actually more desirable, there are legitimate cases where you might select something in preparation to start note input, but decide first to scroll somewhere else to check (like, "hmm, what did that similar passage look like 16 measures earlier)", and then after checking, it's not not to have to scroll back but instead just press "N". To me that's more important to support than worrying about a user who both a) forgot he had something selected, and b) forgot to select something else. But anyhow, that would remain the one case where could conceivably still be surprised by a jump.

Reply

• Oct 25, 2019 - 08:50
Status PR created ⇒ fixed

Fixed in branch master, commit 8f7580eb70

_fix #296053: improve algorithm for determing start point for note input

Resolves: https://musescore.org/en/node/296053

The algorithm for finding a start point for note input works well in most cases,
in particular, if a measure or a note or reset is selected.
The cases were nothing is selected, or an element other than a note or rest is selected,
are sometimes good, sometimes we give up too easily
and select the first (or first visible) measure.

This change improves the no selection case by using the last-selected CR if it is in view
(using the recently-added code for remembering the last selected position).
It improves the case of soemthing other than a note or rest select
by using the actual tick of the element
rather than trying to guess a tick by looking for a parent measure.
That works for elements that are ultimately parented by a measure,
but fails for things like spanners, which are children of the system.
It turns out that SpannerSegment had no tick() function, so this failed at first,
but I added an override, which may well fix some other bug somewhere.

Another side benefit of the change is that if select an element not at the start of the measure
(for examplea mid-measure staff text), input starts at that tick,
not at the beginning of the measure._

Reply

Fix version
3.3.0