Incorrect parsing of .mid file (FIXED)

[james.fleming]

Hello, we have a midi file where it looks like Reaper parses the MBT incorrectly following a BPM change event. I've attached the file. You can see the bug in the "EVENTS" track.

Reaper lists the EVENTS track like so:
Index MBT
526 46.1.000 0.0.60 D0
527 46.1.235 0.0.60 C#0 <- this is the bug...

But looking at the midi file (using 2 different parsers), the events are:

tick SECONDS MBT
86400 0:01:30.002 46:1:000 NOTE_ON channel=1 note=26 (D1) velocity=100
86460 0:01:30.065 46:1:060 NOTE_OFF channel=1 note=26 (D1) velocity=64
86640 0:01:30.254 46:1:240 NOTE_ON channel=1 note=25 (C#1) velocity=100

So there's the bug. Reaper says it's at 46.1.235, but it's really at 46.1.240, the delta ticks are clear.

Interestingly, there is a tempo shift at 46:1:005:
0:01:30.008 46:1:005 TEMPO 119.20 bpm = 503355 us/quarter
which is exactly before Reaper gets it wrong. Interesting too that Reaper is off by 5 ticks, and the tempo shift is at 46:1:005, five ticks in.

I've attached the .mid file. We are using Reaper 5.12/x64 rev ef6009 Jan 21 2016.

For our usage, tick accuracy is very important! Thank you. -James

[Dstruct]

Same in 5.18?

[james.fleming]

Yep, just got 5.18, and loaded and verified. Looks the same.

[DarkStar]

? Am I looking at the wrong MIDI?



That was the MIDI on channel 1.

[ivansc]

Yep - I just opened it up in both reaper and Sonar Pro and see nothing out of the ordinary.

OP: what are you doing your file viewing in?
Dstruct: are you saying you too have this issue?

[Dstruct]

No, didn't test it.

[DarkStar]

On further diagnosis I get different results depending of the choices I make (both when dragging the MIDI file from Explorer onto the Arranger):

. . . .

[Big pics: url]https://i.imgur.com/hVo1dRb.png[/url] and https://i.imgur.com/Kxt6R0t.png

The distance and note length is doubled in the second one! But they both look wrong to me.

Here is the same MIDI in energyXT:
>>> https://i.imgur.com/n1ezuDP.png

-- the position is in beats.ticks
-- and the length is erroneously report as 1 tick to many.

[Justin]

I'm guessing the reason for some people having different behavior is:

Preferences/Media/MIDI: "Snap tempo change events to whole beats when importing MIDI files".

Edit: looks like it is some rounding code in the project tempo map logic, due to the tempo marker being very close, but not exactly on, a measure start. Will see about fixing this (tricky, though, so the fix may not get into a release in the near future). For now enabling that snap option will help.

[DarkStar]

Just for info:
"Snap tempo change events to whole beats when importing MIDI files"
is not enabled here.

[ELP]

"looks like it is some rounding code in the project tempo map logic"

Sry Justin but I would write:
looks... there is some float rounding code differences behavior
between MIDI timebase source|raw vs project timeline from/to MIDI tick logic....... and not only with tempo events/map -which are not snap to beats......



----
BTW darkstar:
"note length is doubled in the second"

that´s because the MIDI is 480ppq and import with the option
"Single channel items on multiple tracks"
change the source ppq to your project ppq...
It split channel events to different tracks and for that REAPER create new MIDI 'Items ..
You have 960 ppq as project ppq so 60 ticks from 480 ppq result in of course 120 ...

You can see this within source item properties that only
"Single channel items on multiple tracks" change the source ppq to your project ppq

[DarkStar]

Good explanation; I did wonder.

Yes, I have 960 ppq - so that's another bug in the Import - the result should be consistent and take into account the PPQ in the file and the project setting.

[ELP]

Personally I strongly advice to snap everything to grid.
specially left midi item edges and tempo events....

BTW Justin the lowest possible, working timeline positions ( working means without to earn rounding/bug things) refers to snap|positions for tempo events at timeline
is 1/128T ... Import to whole beats is not really an option, it is an workaround....

Lice..
Look at the measure position 3.1.00 and the note ... !
If i move the tempo event to grid snap 1/256 means lower 1/128T...
You earn errors/event position errors, rounding problems..
and if you now edit/quantize or whatever with timebase to project beats... and not source beats........

This occurs only on every start of a new measure . Tempo event Position < 128T In front and after one new measure = The position of the measure commutes..
And that´s why the above MIDI example with it´s tempo events looks like it looks ...



All these old rounding problems is really one big bang... simply by the fact that many user not always snap everything to at least example 1/128...
If I thing about that much people
resize the left edge of items often without grid|by hand... do offsets without grid or simply think about recorded tempo events ....... these are never snap to
anything... and so on and so on..

--------------------------
Edit:
commutes fixed with 5.20 beta4

lice from -5.20 beta 4
works now also without snap


Thank you
--------------------------

[DarkStar]

... and the PPQ conversion? (480 in the MIDI file, 960 in the preferences)

[ivansc]

DS: Now thats an interesting thought - PPQ mis-matches...
I am embarrassed to confess that I dont usually even check when importing OPM (other peoples MIDI)

I will in future though...

[DarkStar]

I didn't look at it either; it was ELP (no relation?) that spotted that problem.

So this thread shouldn't really be marked as [Fixed] (not yet, anyway).

[ELP]

Do you have the feel that this should be marked as one bug? I not really.

Ok REAPER is the only DAW/SEQ, which I know, that can do "MIDI item PPQ mis-matches"
It is of course not the same, but a little bit like,
project sample-rate|different Media item sample-rates.
(glue after import as only one example would change the item ppq to your project ppq..)

The confusion|fault or whatever is more that there is one import function/way,
which change the file ppq to project ppq. I mean directly during import.
And this is these
"only channel events to different REAPER tracks...

[DarkStar]

Maybe it should be in a new thread, but I did find it while investigating the original bug report

[ELP]

but then the preferences option for one global project ppq "for the MIDI items" should be/must move also to project/song settings..

Simply by the fact that I can work and save REAPER RPP with different ppq settings..
But if you load one of this projects the MIDI item PPQ do not change to your preferences ppq. I mean automatically during load
They stay at their different ppq. In principle this is the same behave, like with MIDI Files.

I know the possible PPQ mis-matches since years and I really don´t find it is a bug
For me it is more a feature.. this way files always load as they were saved and nothing change automatically during import.. except, of course, channel to different REAPER Tracks.