MIDI Player/Transport bugs & info requests

[ustk]

I am working on a midi project, I'd like to get some info on non-documented methods.
I'm also reporting some bugs that will be pushed as git issues.

DOC INFO:
What are these functions supposed to do exactly and how to use them properly?

• setEnabledGrid and MidiPlayer.setSyncToMasterClock since they are related

• sendGridOnNextCallback. I might not fully understand what the grid is finally...

• startInternalClock and stopInternalClock. Something seems to happen but I can't understand what they are doing. Also it seems I have strange bugs like the impossibility to stop a loop once it is playing (in fact it stops but plays again without asking at next beat or so...) (probable conflict with syncMode, at least in my head...)

BUGS

• Next midi player loop misses the last beat and de-sycn from tempo a bit more at each occurence if Loop Enabled. Similarly it strangely misses the first beat if Loop is disabled, but since it shouldn't even loop…

• ...Loop is Always activated no matter the button state (but still, something happens seeing the bug above)

• Engine.getPlayHead() throws an empty object. It might not be populated and related to this thread -> source-change-request. And why a playHead thing is part of the Engine class?

SIDE QUESTIONS

• How to properly sync a loop with DAW? I mean I can get it to play, and resync using a beatChanged callback. But this means it doesn't necessarily resync on first beat of next bar. Or should I just make a flag and use the isNewBar property?
  Or should I compute the DAW bar pos (or get it from Engine.getPlayHead) and feed it to the midi player as a 0-1 based playback pos?

• Is MidiPlayer.setGlobalPlaybackRatio() a good method for playing at different tempo (DAW, local, file...). I can get it to work but not sure it is safe enough since the DAW sends it's tempo and here I just compute a ratio of my own to make the playing right. Is there no direct way of setting the playback tempo instead?

[Christoph Hart]

How to properly sync a loop with DAW?

Sync the MIDI player to the HISE master clock and then use the external sync mode, then you don't need to do anything else for DAW syncing.

[ustk]

@Christoph-Hart And when I want to play at a different tempo than the DAW one? Is the playback ratio the solution?

[Christoph Hart]

No then I would switch the HISE clock to internal and change the BPM (I think the default Engine.setHostBpm() should work there).

[ustk]

@Christoph-Hart Thanks! Trying...

[clevername27]

@ustk There's a lot of complexity (the good kind) in the API here. I've been a little overwhelmed myself, and have some questions – but take a look at the code examples in the docs and in the forum. It's helpful that there's a sequencer right there in the interface designer, and you can test stuff out without exporting to a plugin.

One use of the grid stuff is for things you want synched to a clock, but in different units than the bpm - like an LFO or delay.

I've encountered the first two issues you described, but (at least for me), I'm not convinced yet that it's not simply my own ignorance of how to use these things. But it's good to know I'm not alone - we can probably figure a bunch of this stuff out together.

In terms of your getPlayHead(), see my post about it from the other day - it sounds (see what I did there) like everything you're trying to do can be done without it - but if you want it, simply replicate what I posted, and recompile HISE. But the TransportHandler is easier and more efficient if it does what you need — premade callbacks are dope. I'd suggest focusing on that as @Christoph-Hart indicated.

If you're still having problems, post a description of exactly what you're trying to do, and I'll try to help.

[ulrik]

@Christoph-Hart said in MIDI Player/Transport bugs & info requests:

No then I would switch the HISE clock to internal and change the BPM (I think the default Engine.setHostBpm() should work there).

The Hise clock, it it the same as changing the gridsync to prefer internal?
Cause that's what I'm doing and the Engine.setHostBpm() is not changing anything in that case?

[ustk]

So two things I narrowed down a wee bit:

• The loop end seems to happen after the last note-off event, meaning that if you have only one note, let say the first beat for a quarter duration, it's looping back to the beginning at the second beat instead of lasting 3 more beats of silence.

• A side effect of this is that the NbBars property in the midi file metadata depends on this duration, no matter it is containing 4 beats. (So even if you round this information you never know what you get since a 4/4 bar can be rounded to 0 if you have only one short note...)

Side question:
I have seen 4/4 measures having a last note off exceeding the bar duration, leading to a bar length (NbBars) > 1
What happens to that note-off after looping?

[ustk]

@Christoph-Hart Alright, so the early loop end issue seems to come from the fact the EndOfTrack event isn't read...
It should also be used for the NbBars calculation