Is this a note entry bug?

• May 30, 2015 - 18:37

Please open the attached file.

When I enter a certain sequence of notes in two voices I get some unexpected results. This is all explained in the file.

Incidentally, MuseScore crashed shortly afterwards so this may be a critical bug. As I am a beginner I'd prefer to get this confirmed before reporting it as an issue.

Attachment Size
notation_anomaly.mscz 9.05 KB


The first part - the fact that pressing "left" moves to the beginning of the bar - isn't a bug, exactly, but a consequence of a change made at user request pretty recently. The arrow key formerly acted on the"not input cursor" - the box. It was requersted for various reasons that it instead act on the selected (highlighted) note or rest. This makes sense when moving forward - hitting right arrow instead of left in your scenario. It would bring the selected note and note input cursor in sync, rather than move the note input cursor forward, which helps when entering chords. But I would agree the original behavior made more sense when moving *backwards*. Probably we should do a special case and go back to the old behavior in that case. Feel free to file an issue to the tracker (use Help / Report a Bug from within MuseScore).

EDIT: actually, the code *is* smart enough to do that *most* of the time. The only issue is this special case you are seeing because the note input cursor has moved on to the next measure and there is nothing in voice 2 in that measure. That is the only case where there seems to be an issue. But I'd still call it a bug.

The second part is not a bug. The cursor cannot be moved to positions where there are no notes. The note input cursor automatically moves there during note entry, but note the rest in bar 2 remained selected, and it is that selection that you are actually controlling with the arrow keys (as seen above). Just re-enter the rest.

If you find steps to reproduce a crash, that is obviously a bug, so definitely report that!


The arrow key formerly acted on the "not input cursor" - the box

Please read:

The arrow key formerly acted on the "note input cursor" - the box

The most important thing is that the program behaves consistently. Is it worth adding a note on this topic in the manual?

In reply to by geetar

I think it's more worth fixing the bug you found so that *is* consistent :-). I think the rule should be, when the selection and note input cursor are in sync already, the arrow keys should move them together. If they are *not* in sync - which normally happens just after entering a note - then the arrow key should have the effect of moving one but not the other to make them in sync. Right now this *almost* always true. As far as I can tell, it fails only the very specific case you mention: immediately after entering the last note in a measure in voice >1 (and only if the next measure had nothing in that voice). So I am proposing fixing that case.

In reply to by Marc Sabatella

In your opinion, do you know if this reported issue on the French forum is related or not (seems, maybe?) : - because I don't understand very well your previous comment/reply and the fix proposal :(

To reproduce with this file: test saisie voie 2.mscz

1 - Select the 1st note in voice 2
2 - "N"
3 - move the cursor with the right arrow key
4 - arrived on the C (half note), press Del
5 - press the right arrow key to move to the next step to continue typing ...

Either there is no way to move the cursor with the arrow keys
Either the cursor jumps several steps further
Either the rest goes in edit mode and moves with the up and down keys .

For my part, I received a crash (and only one despite other tests), after the deletion of the C, then move in the second measure with keys right + up (in my memory) and type a note in this measure (as you can see on this image of the crash)

In reply to by cadiz1

The issue being discussed here is the following:

1) new score, 4/4
2) measure 1, note input
3) switch to voice 2
4) enter 4 quarter notes

At this point, after entering the last note in measure one, it should be highlighted, and the cursor should be in the measure two. Now press the left arrow. I would expect the note input cursor to return to the last note of measure 1. But it doesn't - it goes back to the note on beat 3. This works as expected if you don't switch to voice 2.

What you are descirbing is something else, although perhaps a similar cause. Upon pressing right arrow, the cursor has nowhere to go - it can only travel to places where there is note or rest. And once you do that, the cursor is now at a position where MuseScore cannot figure out where you want to go even if you press the left arrow, although it probably *should* be able to.

I can't reproduce a crash, but if you have precise steps, please post!

In reply to by Marc Sabatella

FWIW, #63176: Note input cursor glitches for voice >1 when advancing into gaps.

Even with my fix, it would still be the case that certain combinations of deleting the element under the cursor can break navigation. The issue is that after deleting an object nothing is selected. Sometimes people suggest something else *should* be selected, but that's not really good GUI design from my perspective. Anyhow, if you delete a voice 2 *rest* and there is nothing else at that time position on that staff, navigation is going to struggle. But the cases described here should all be improved.

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