wrong MIDI on/off for (beamed) tied notes

• Aug 3, 2017 - 20:56
Reported version
2.1
Priority
P2 - Medium
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

Version: 2.0.3+dfsg1-2+b1

The attached image shows a measure which is exported to MIDI wrong, caught by my script to check for note collisions, but a totally different kind of code bug.

Look at the CSV data from midicsv, only for MIDI note 64 (E4):

$ grep -n '^., 5[0-9][0-9][0-9][0-9],.* 4, 64,' 'Look at the world.csv' | tr -s ':, ' ' ' | sort -nk3,3 -nk1
2192 5 53760 Note_on_c 4 64 80
2194 5 54443 Note_on_c 4 64 0
2195 5 54480 Note_on_c 4 64 80
3965 6 54480 Note_on_c 4 64 80
3966 6 54707 Note_on_c 4 64 0
2198 5 55163 Note_on_c 4 64 0

(The command line keeps the file ordering for events occurring at the same time. I cropped the output to what’s relevant for this measure.)

As you can see, first, the punctated quarter note is played (in track 5), correctly, from 53760 to 54443 (just before the beginning of the fourth eigth-note in the measure). But then it explodes:

The eigth note plus tie is started in track 5 and 6 at the same time; track 6 lets it end at 54707 (end of the fourth eigth-note in the measure), track 5 keeps it running until 55163 (end of the sixth eigth-note, i.e. end of the tie).

This effectively means that a cross-beam plus tie has the crossing/last note played in BOTH the lower and upper stave (i.e. MIDI tracks 6 and 5, here) in the _same_ channel, and the tie is played in the upper stave for the entire duration.

I think refcounting as mentioned in https://musescore.org/en/node/12971#comment-759801 needs to keep an actual count of how often the note was attempted to be started, and decrement it each time it’s unplayed, and only emitting an “on” on 0→1 and “off” on 1→0 passes, instead of just dropping an “on” when the note was already on and same for off/off (which could have been done with a boolean field), then it could fix this issue as well.

Attachment Size
x.png 11.93 KB

Comments

Priority P1 - High P2 - Medium
Status active fixed
Frequency Many
Reproducibility Always

With 2.3.2 with restriking, this becomes:

2199 5 53760 Note_on_c 4 64 80
2201 5 54443 Note_on_c 4 64 0
2202 5 54480 Note_on_c 4 64 80
2203 5 54480 Note_on_c 4 64 0
3977 6 54480 Note_on_c 4 64 80
3979 6 55163 Note_on_c 4 64 0

The weirdness around 54480 is a good reason more to get eventually rid of the restriking patch ☺ but the problem itself is fixed.