Still trying to make sense of Tempo, Sync, and MIDI loop issue

[ustk]

@Christoph-Hart Well apparently it's the same thing from Pro Tools... I have to try another DAW...

[ustk]

@Christoph-Hart Well that's a bit too weird... I tried exporting from Ableton, Cubase, Pro Tools and Reaper, same thing... Knowing that I selected "Export Locator Range" in Cubase and "Time Selection Only" in Reaper

Same issue from 4 major DAWs isn't a coincidence... I wonder which DAW has been used for the library you downloaded so I could test it... Or perhaps there's a ghost note that has the noteOff right at the end of the bar? This is the only trick that I found to make it work...

The MIDI Viewer still considers the last noteOff...
Could you check the last noteOff timestamp in your MIDI files to be sure it is BEFORE the end of the bar? This would be the only indicator that tells if it's the endOfTrack that is then read, or a ghost note...
Or the endOfTrack timestamp in this file -> Cubase 4-4 1bar noGhostNote.midi.zip

When I re-import back into a DAW, I obtain the full bar length, meaning the endOfTrack is where it should be I think.
So I think Hise still doesn't seem to read it... Or is there another indicator for the bar length?

(before you ask, yes I updated Hise because I can see the new setLinkBpmToSyncMode method :) )

[Christoph Hart]

@ustk I just checked the file and it has an end of track marker, however the event has a timestamp of zero (so it can‘t deduce where the actual event is).

[ustk]

@Christoph-Hart Interesting... And what about the one from the library you downloaded yourself? It would be weird that all files exported from 4 different DAWs have the same issue.
Could you please send to me the one you used? I'm lost with all these weirdnesses...

[ustk]

@Christoph-Hart Is this normal that I have to set the tempoFactor of setEnableGrid to 0.5 in order to get the gridChange to be in sync?
setting to 1.0 doesn't simply double the speed but make it to trigger at a weird tempo...

[Christoph Hart]

@ustk the tempofactor is the enum from 1-18 (check the values by setting a slider mode to tempo and then read out the integers). 1 is probably 1/1D or something which some people without a feeling for polyrhythms might call „weird“ :)

[ustk]

@Christoph-Hart Oh that makes sense in this case!

some people without a feeling for polyrhythms might call „weird“ :)

Then I don't !

[ustk]

@Christoph-Hart After testing this in all ways I could imagine, this endOfTrack issue still doesn't make sense to me.
Effectively the EOT timestamp is wrong in the library I am using.
But this library is playing nicely in other players, meaning they are not taking the EOT into account (or they fall to another calculation method when the EOT is wrong)

Even if somehow we fix the EOT timestamps of the library, since the exports from major DAWs also have this issue, what will happen when users make their own midi files exports from any DAW? They won't play in our player despite they will work in other players...

All of this tells me that it is Hise that should take care of the sequence length, isn't it?

Another consequence is that the MidiView or rectangle list also reflects this wrong sequence length

[Christoph Hart]

@ustk I've just pushed a commit that will round up the value if it can't be detected properly (which I'm guessing is everybody else doing since there is no other way to retrieve that information).

[ustk]

@Christoph-Hart Great! I will test this asap!
I agree with the principle, and that's what I am doing in the midi browser to display the right sequence length.
I just couldn't do the player side of it, so thanks!