MIDI unison bug -- could be major

• Oct 6, 2019 - 23:33

OS: macOS 10.14, Arch.: x86_64, MuseScore version (64-bit): 3.3.0.23833, revision: d3bff12

Direct unisons produce a bogus midi file. Reading it back in produces an even more bogus score.
Open the attached 2-measure score midibug.mscz. Looks fine, plays fine. First note is 2 flute parts in unison, D4. Export a standard midi (midibug1.mid).

t# chn relT absT m+beat
Track 0: Meta 6, Control/ch: 0:6, Notes/ch: 0:16

0 0 0 1+0 Time Signature: 1 / 4
0 0 0 1+0 Key Signature: C major/A minor
0 0 0 1+0 Set Tempo: 120 q/min, data [7, 161, 32]
[control changes]
0 0 0 1+0 MIDI Port/Cable: data=[0]
0 0 0 0 On D 4 1+0
0 0 0 0 Off0 D 4 1+0
0 0 0 0 On D 4 1+0
0 0 455 455 Off0 D 4 1+91/96
0 25 480 2+0 Time Signature: 4 / 4

As you see, the second note is shut off at the time it starts. That might be okay, depending upon what kind of tool read it. MuseScore reading it, however, is completely confused, and thinks there is only one very, very short note. MuseScore read-in also attached, midibug1.mscz. The midi artifact is arguably wrong (my tools have to notice this). The read-in artifact is completely wrong. (FYI, no, I have not used my articulation plugins on any of it).

In MS2, the readin behavior depends on "simplify durations". In MS3, it is wrong regardless, gets different short notes depending upon "simplify durations".

Summary - musescore should (a) not generate zero-length notes (b) disregard them on midi input. Whether it should generate "on, on, (later), off, off" is a different issue.