Identical subsequent notes disappear on MIDI input
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 |
Fix version
3.0.1
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.
Hopefully better title
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
Confirmed. Very likely related to #280771: Crash on adding notes in voice 2 using MIDI or piano keyboard input
BTW, this seems identical to other reports, including:
- https://musescore.org/en/node/280662
- https://musescore.org/en/node/280654
I just fixed the issue Marc said it might be related to (#280771: Crash on adding notes in voice 2 using MIDI or piano keyboard input). But although maybe related, it doesn't seem identical as the fix for that didn't fix this. I will investigate this issue now.
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.For reference, that line (and it's surrounding block) was added 6 days ago by jthistle to fix #280365: Chord Input Piano Keyboard with commit message "holding shift and entering notes with piano doesn't form chord": https://github.com/musescore/MuseScore/commit/aec865285b3cd345f084b2f2f…
the two bugs (this issue and #280771: Crash on adding notes in voice 2 using MIDI or piano keyboard input) are "related" in that they are both related to that same commit for that fix for #280365: Chord Input Piano Keyboard, which was merged 5 days ago: https://github.com/musescore/MuseScore/pull/4473
PR created: https://github.com/musescore/MuseScore/pull/4510
Yes it seems to be caused by 6e365e2. It works as expected with nightlies before.
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
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?
Fix typo in issue title.
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.
Fixed in branch master, commit 109f7af218
Merge pull request #4514 from ericfont/280715-identical-midi-pitch-inputting-better
fix #280715 shift+midi in don't delete old
Automatically closed -- issue fixed for 2 weeks with no activity.