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

[Christoph Hart]

MIDI Player doesn't loop at the endOfTrack event, but after the last note off instead resulting in a truncated sequence.

I'm such an idiot it isn't even funny anymore. The end of track event was in there all along, I just deleted it :) It's fixed now ...

setOnBeatChange doesn't fire at the first beat

Yup, use the start / stop callback for that (or if you don't want to duplicate the logic, just call your onBeatFunction in the onStart callback manually).

When Internal sync is selected, the playing speed still reacts to DAW tempo change.

Yeah that was kind of messy (it checks whether you've called Engine.setHostBpm()). I've refactored some code relating to this and added a new function to the TransportHandler that will link the bpm to which mode is currently active. So if this is enabled, it will use the internal BPM if the sync mode is Internal and the host bpm if the sync mode is external (if you set the internal bpm to -1 it will always use the host bpm and if the host bpm can't be detected it will use the internal bpm).

In the real world, I am using setOnBeatChange to play the next sequence (number of bars in the seq times a counter+isNewBar)

No, the accuracy of the beat change callback might not be enough. Use the onGridChange callback, this will get you a sample accurate position with a timestamp within the current buffer.

[ustk]

@Christoph-Hart said in Still trying to make sense of Tempo, Sync, and MIDI loop issue:

I'm such an idiot it isn't even funny anymore. The end of track event was in there all along, I just deleted it :) It's fixed now ...

Amazing! Thanks!

Yup, use the start / stop callback for that (or if you don't want to duplicate the logic, just call your onBeatFunction in the onStart callback manually).

Well, the idiot is me...

Yeah that was kind of messy (it checks whether you've called Engine.setHostBpm()). I've refactored some code relating to this and added a new function to the TransportHandler that will link the bpm to which mode is currently active. So if this is enabled, it will use the internal BPM if the sync mode is Internal and the host bpm if the sync mode is external (if you set the internal bpm to -1 it will always use the host bpm and if the host bpm can't be detected it will use the internal bpm).

Nice! I'm checking this ASAP
But this confirms how setHostBpm term is confusing to me, since it is not necessarily the host that it sets for all values except -1

No, the accuracy of the beat change callback might not be enough. Use the onGridChange callback, this will get you a sample accurate position with a timestamp within the current buffer.

Oh of course how couldn't I see this! Math.pow(idiot, greg)...

[Christoph Hart]

But this confirms how setHostBpm term is confusing to me, since it is not necessarily the host that it sets for all values except -1

Yeah, it was super convoluted and prone to weird edge cases, but I think I've boiled it down to a very simple logic:

if(linkBpmToSyncMode) // this is the new function TH.setLinkBpmToSyncMode()
{
    if(syncMode == Internal || syncMode == PreferInternal)
        return internalBPM;
    else
        return hostBpm;
}
else
{
    if(internalBpm != -1)
        return internalBpm;
    else
        return hostBpm;
}

[ustk]

@Christoph-Hart Hmmm... It seems the endOfTrack is still not taken into account for some reasons

The NumBars meta should be 1.0 in the above 4/4 sequence example, but is 0.79270833333 in reality, which again seems to correspond to the last noteOff

This is the midi file in question:
Rock Groove 01A Bsc Qtrs cl hats.mid.zip

Could the endOfTrack be at the same timestamp as the last noteOff?

[Christoph Hart]

@ustk yes. I noticed that when you export a clip from ableton it will also set the end of track to the last note off.

[ustk]

@Christoph-Hart hmm that's annoying... Someone will not be dancing when learning this

[Christoph Hart]

But I downloaded a random MIDI pack (took me a few minutes to find something that didn‘t want my email address in exchange) and with those it worked so the end of track is definitely detected now).

[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!