Note Entry - wrong position with no selection and last selected note in voice >1
Steps (3.5Alpha):
1) Load basic score attached:
2) Select first note of 2nd voice
3) Press 'V' to make invisible so that the note connects with its upper voice
Notice the slur automatically shifts position as expected by the algorithm.
4) Select that slur via keyboard [alt+right] and press 'x' to flip it back to bottom position
5) Now, exit edit mode (or i have a temptation to just press N but then there's the "slur is still selected while in note-entry error") by pressing Escape.
6) Press N
Result: Position is not at that appropriate time-segment but ends up at the previous measure (the reason for the first empty measure for demonstration), which might bring the user a full system back or two or somewhere else depending on the score.
Expected: the position should be at that first note of the measure when first selecting the note.
Included demonstration:
(including the slur motion while in note entry from step 5 (notice that the note entry position is correct when pressing "N" directly from editing the slur but not when escaping from out of editing it in this situation):
| Attachment | Size |
|---|---|
| note-entry_pos.mscz | 4.14 KB |
Comments
a) is this a 3.5 Alpha regression, or did you just detect it there first?
b) (if the former) does it still exist in later development builds?
In reply to a) is this a 3.5 Alpha… by Jojo-Schmitz
a) The latter. I.e., 3.4.2 also has wrong placement into note-entry within the mentioned context, yet upon further testing, interestingly the slur doesn't shift to the note-head side when making invisible the second-voice as it does in 3.5, but that's an aside and not important to this topic.
b) master-branch also gives same said behavior.
ciao.
I think the invisible note, the slur, the flip, and the use of note input mode are all red herrings here. I can reproduce this simply by having two notes in that second measure, one in voice 1 and the other in voice 2. Click the voice 2 note to select it, press Esc to unselect, then press N. Same result.
So it seems that the mechanism we introduced to remember the last location selected when pressing N simply doesn't work if that location is in voice 2.
Looking at the code for ScoreView::startNoteEntry(), I can see are looping through the visible elements on the page, "looking for the CR in voice 1 with earliest tick and highest staff position", but that we should stop when "we find the last selected CR". However, we don't check to see if we've found the last selected CR until we've already skipped the notes not in voice 1. So in theory, we would just need to hold off on the "continue" for voice > 1
This is mostly code I wrote, so I'll see about the fix.
So I tried, that and it works well enough, but because the code is re-selecting the last selected note and then starting note input, I find myself in voice 2, which I think would find surprising. Recall, after all, we are talking about a case where nothing at all is selected. The user might not even remember he had previously selected something in voice 2. So I'm thinking it might make more sense to start note input at the start of the measure in voice 1 in this case instead. Thoughts?
In reply to So I tried, that and it… by Marc Sabatella
Hey Marc, makes sense since the general behavior is to begin note-entry in first-voice, just how it happens upon activating note-entry directly when a slur is selected without first pressing escape, even if the slur is attached to notes in a secondary voice.
Aside: Upon further reflection, I think this is another proof that the bug about the slur still being selected when directly going into Note-entry #303426: Slur continues to be moved after leaving edit mode from Note Entry gets a +1 for its needing to be fixed sometime hopefully sooner than later in the meantime, since as it is, it's like between a rock and a hard place:
1) Press escape first and then lose the right position after pressing 'N'
2) Or, press 'N' without pressing escape to get the right position in note entry, but suffer the consequences of having the left/right arrows not move the entry highlighter but rather the previously selected slur instead.
I just checked the issue and a user claims to have "took up the task" but has yet to show any active PR yet. It would be neat if that and your fix were also implemented soon.
ttyl
To be clear though, the real solution is to simply make sure you’ve selected an actual note or eat before entering more input mode, otherwise we have to guess and it’s hits or miss. Don’t rely on guessing, always select a note or rest. No rocks, no hard places, just nice soft landings.
In reply to To be clear though, the real… by Marc Sabatella
Yeah, makes sense of course. There is something slightly awkward with navigating in notation so far as I've experienced with the keyboard depending on one's mindset though. Like, if after making some slur alterations it's desired to continue on the next note in the second voice, MS's [alt+right] will take the user to voice-1 and not voice-2, and actually only an [alt+left] will get to voice-2 in its 'precedence' which then in turn could be followed up with regular right-arrow presses. It's not that big of a deal actually, just sometimes it isn't 100% intuitive but it becomes easier with time.
It seems to me that this is one of the few instances where mouse usage, depending on how you look at it, has an advantage.
Fixed in branch 3.x, commit e5a4fa9e72
_fix #306371: wrong note input position if last selected in CR in voice > 1
Resolves: https://musescore.org/en/node/306371
When entering note input mode with no selection,
we try to find a good location to start.
Originally this was the top left visible CR of voice 1.
A while ago I added code to favor the last selected CR,
but since we were looking in voice 1 only, we never found it.
Fix here is to check for voice >1 in lastSelected, and if so,
find a CR in voice 0 instead.
Alternative would be to go ahead and start note entry in voice 2,
but to me this felt too surprising given we are talking about a case
where nothing is in fact currently selected.
People generally expect note input to start in voice 1
unless they explicitly selected something in voice 2._
Fixed in branch 3.x, commit b5c26d1c6c
_Merge pull request #6179 from MarcSabatella/306371-start-note-entry
fix #306371: wrong input position if last selected cR in voice >1_
Fixed in branch 3.5beta, commit e52686e28d
_Merge pull request #6179 from MarcSabatella/306371-start-note-entry
fix #306371: wrong input position if last selected cR in voice >1_
Automatically closed -- issue fixed for 2 weeks with no activity.