Playback Wrong Notes

• Oct 7, 2020 - 02:29
Reported version
3.5
Type
Ergonomical (UX)
Frequency
Few
Severity
S4 - Minor
Reproducibility
Randomly
Status
active
Regression
No
Workaround
No
Project

Steps to reproduce the issue.
1. Playback the melody and on the second measure, the playback is wrong for the last beat.

Attachment Size
Untitled.mscz 20.97 KB

Comments

Frequency Many Few
Regression No Yes
Reproducibility Always Randomly
Type Functional Ergonomical (UX)

@lmcdonal the last note in the trumpet has been moved. It's a D# that is placed where a C# belongs, so I'm guessing you wanted the note to be a C#. Notice that there is no ledger line, this is a sign the note has been moved. You probably did it by accident. If you double click a note, it is put into edit mode and dragging it with the mouse will only change it's visual location and not the pitch. To fix it, select the note, open the inspector (F8) and set the X & Y offsets in the chord to 0. You can then change the note's pitch.

Programmers:
I'm going to do a few things with this issue because this needs to be looked at. I'm guessing this is about the 5th person to have this happen recently. First, I'm going to keep it active rather than closing it as "by design" as we have done with the others who have posted this in the issue tracker. Next I'm going to change the frequency to Few since I know it's more than one but I'm not sure it's 5. I'm going to set the Reproducibility to Random since this should not be happening and no one has explained the exact circumstances to make this happen. I think this is an ergonomical bug (clicking the mouse). Last of all I think it's a regression.

The problem is that users who use the mouse to enter notes also drag the notes to change the pitch. This is fine for editing scores in MuseScore even though more experienced users rely on keyboard input and don't experience this. It seems they are accidentally putting the notes into edit mode and changing the offsets for the chord rather than the pitch. These reports have been far more numerous since the release of 3.5 than in previous versions. We've always had the rare reports like this but so many in so short of a time indicates that there may be something to look at here.

I believe this is somehow related to changing it so that clicking certain items put them in edit mode (like lines). I've noticed occasionally also that when I single click a text item, it's put into edit mode.

Since you didn't mention which instruments had the mistake I only looked at the trumpet. The same thing happened to the guitar.

There are moved notes all over this score. Press ctrl+a then ctrl+r and all of the notes will be back where they belong. You can then fix the wrong notes.

I'm not advocating holding up 3.5.2 over this issue but I consider it a regression because the problem didn't exist before the change was made that put a single clicked line or slur into edit mode. I'll leave the final decision to someone else.

OK, surely not a 3.5 regression then I believe. Not sure exactly when that feature got introduced though.
Still, you need a double click to put a note into edit mode and change its y-offset, so the single-click edit mode for lines has got nothing to do with this.

But yes, this does need to get looked at, it came up quite a few times lately

People have been accidentally dragging notes in edit mode for a very long time, nothing remotely new about it except maybe it does happen slightly more the last few months somehow. I'm of the opinion we should disable dragging as a way of changing pitch. That's what people are trying to do here, and the problem comes up if they accidentally double-click instead. There no real reason to allow transposition by drag as far as I'm concerned.

In another post in the forum I mentioned that dragging a note to change the pitch is a legitimate way to do this and it should remain as well. This does seem to have more reports recently, from my observations, since single click put lines into edit mode.

It's possible, as that changed surely would have touched event-handling code and who knows what unintended side effects are possible. But if there really was a regression, to me it seems more likely to have been triggered by the changes the last few releases to the horizontal note dragging semantics. Still, I can't reproduce a problem. For me, it's 100% reliable that a simply drag transposes, only after an explicit double-click do I get the offset adjustment.

Actually, what strikes me as being at least as likely an explanation for any perceived increase in frequency is that some new model of touch device started hitting the shelves, or some new driver update, that is more sensitive to double clicks.

Speaking of unintentionally moving note heads, I've recently triggered that option multiple times when trying to change the pitch up or down instead. Perhaps the double click tendency came from previous versions where we had to click twice to enter an editing mode?