MIDI type 0 note ends don't display correctly when split into tracks by channel

[PelPix]

This is a bug I've been running into on and off for the past 10 or so years when I try to load old midis from 90s games into REAPER.

Steps to reproduce:
Load an old type 0 midi, usually from a game (this is music2.mid from the AoE2 OST)
Select "single channel item on multiple tracks"

See attached for what (occasionally) results. This also still happens if you select the other option and then explode it in item processing.

If you select "multi channel item on single track" and then filter to the same channel, it displays correctly. This seems to happen with certain specific midis, but I haven't figured out precisely what causes it. As far as I can tell, this only happens with affected midis in REAPER.

[schwa]

Can you post one of the .mid files that causes this behavior?

[PitchSlap]

Pretty sure this is the same bug.
It also affects the unsplit MIDI file in the Media Explorer.

Note ends seem to extend creating an overlap, and then don't display correctly.
Quantizing the note ends corrects the issue, but as can be seen below, if a different track is opened and the same quantize setting is then bypassed, if causes the previously corrected tracks to revert to being wonky.


There's also an inconsistency with the track lengths (though it's possible that's a bug with the MIDI export).

Example attached.

[PelPix]

Originally Posted by schwa

Can you post one of the .mid files that causes this behavior?

happily, as long as it doesn't cause you copyright issues

[schwa]

And what channel has the problem?

[PelPix]

Originally Posted by schwa

And what channel has the problem?

4, at the end, for instance. sometimes it can be all of them. sometimes it's only 1 or 2, sometimes it's only some of the notes in any combination of those.

[PelPix]

Originally Posted by PitchSlap

Pretty sure this is the same bug.

this bug only exists in the piano roll

[PitchSlap]

Originally Posted by PelPix

this bug only exists in the piano roll

My mistake. Different bugs then, I was just about to post a new thread when I saw this, but as they both affect type 0 MIDI, maybe there's a common denominator.

I'll create a new thread if/when your bug is fixed and the one I mentioned isn't.

[DarkStar]

IS it because the file's PPQ is 120 (and Reaper's preference setting here is 960

Here are MIDI Event lists for channel 10 in the multichannel clip and the "exploded on import" clips.

[schwa]

The file is 120 ppq but that is not the problem. The highlighted notes in the previous post are equivalent, they are the same length in beats.

The cause is that the file uses running status, which is an old protocol for reducing bandwidth. REAPER is not handling running status properly when filtering by channel. Decoding running status requires looking at every byte in the file which can be tricky to do if you are intentionally skipping some messages. This might be a pain to fix but we'll look at it.

[schwa]

Technical debt from 1983, basically.

[PelPix]

Originally Posted by schwa

Technical debt from 1983, basically.

No worries, take your time! It's so rare I only just now reported it after experiencing it for a while. Excited though. I remake video game music as a hobby and it's always nice to have original midi for reference.