Identical subsequent notes disappear on MIDI input

• Dec 26, 2018 - 22:45
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

I have a midi keyboard plugged into MuseScore. When I play a note, the note appears and then it hovers over the next beat ready to play another note. When I play in another note, the last note that was played in always becomes a rest. I am sure there is a bug in the input.

It happens the most when I try to do a eight, followed by 2 sizteenths

Attachment Size
Screen Shot 2018-12-26 at 2.45.40 PM.png 184.83 KB

Comments

Same here (3.0 release). Some additional info:
The previous note is converted to a rest whenever the same note is input again. So, if I input C, D, E, F, I end up with all 4 notes, if I input C, C, C, C, I get 3 rests followed by one C. This happens with both a MIDI keyboard, as well as the onscreen virtual piano keyboard. It does not happen when entering notes using the computer keyboard.
It also only happens when entering two identical notes directly one after the other. Moving the cursor back and forth, or re-starting note input mode prevents the previous note turning into a rest.

I've just come on to report the same issue. I wasn't getting this with previous dev versions of 3, so it's a recent introduction (probably around the beta or rc stage, I can't be certain exactly which version). I've found playing a chord on my midi keyboard using step time note input will not progress the cursor unless a different chord is played. If I play the same chord, it simply overwrites the existing one. If I play a chord and then the first (lowest) note again on its own, it replaces the chord with that single note. If I play any other chord or single note, including any note in the original chord except the lowest note, the cursor progresses and the new chord/note is added correctly.

Workaround: If I manually use the right cursor after entering every note or chord where the following is the same, then it appears to work correctly. PITA given how repetitive this score is :-)

I've just installed the beta and then updated to the rc and can confirm this is not a problem on either of those, so it's been introduced between rc and release, I suspect.

Working on system: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4747, revision: 96c1f7b

So commenting-out deleteItem(n); on line 2008 in cmd.cpp for Score::processMidiInput() seems to avoid the problem of the previous repeated note getting deleted...of course that is not the fix, because that line is likely there for a good reason.

After some further investigation, I realized PR 4510 still had problems (including transposing). So I've closed that PR.

In chat there were some discussions about what the behavior should be when using shift + midi in for the same note. Turns out if allow indefinate unison pitches, then the code is simpler. I have a new PR along those relaxed conditions: https://github.com/musescore/MuseScore/pull/4514

Regression Yes No

The link explains the problem, but doesn't solve anything. For physical MIDI keyboard the "Shift" behavior isn't necessary at all. Maybe additional checkbox "physical MIDI keyboard" would be a solution? Or just different behavior should be used, when virtual piano keyboard is hidden or visible? (Using physical MIDI keyboard the virtual one is not needed).
Or any simple workaround could be found?

Title Identical subsequent notes dissapear on MIDI input Identical subsequent notes disappear on MIDI input

Fix typo in issue title.

Status PR created fixed

Fixed in branch master, commit 0b2e61746d

fix #280715 shift+midi in don't delete old

A prior PR #4473 (holding shift and entering notes with piano doesn't form chord) broke the ability to input identical midi pitches sequentially. That was because that PR tried handling to ensure that identical pitches weren't inputted into the same chord by deleting the currently-existing note that had the same pitch. That deleting was problematic for a few reasons discussed in chat...

This fix keeps the code simple by not worrying about deleting when input the same pitch via Shift + midi input.

Fix version
3.0.1