MIDI Player/Transport bugs & info requests

ustk

@Christoph-Hart Alright so the loop fix is working but it brings another weirdness.
The first time it loops, beat 1 is played twice, causing a nasty comb filtering:

https://youtu.be/Nu_ce8qOyHE

clevername27

@ustk Thank you for this thread (and thank you @Christoph-Hart for your participation). I've written a proper little snippet to capture incoming MIDI data—both live and from a host. You don't need to pre-set anything (time signatures, tempos or sequence lengths).

https://forum.hise.audio/topic/7483/code-snippet-for-y-all-capture-incoming-midi-notes

@ustk Can you please consider contributing the second half here — the playback portion?

__________________________________ DISCUSSION __________________________________

Specifically, the code to automatically play back the captured events in synch (time and position) with a host. It seems like a short snippet, above the length of what I wrote, could likewise handle all playback scenarios. (Adaption to playing back recordings of live MIDI data would then be trivial.)

Below are examples of what I'm (and others) are struggling with. I realise some of these questions have been answered in this thread, but my wayward brain can't seem to assemble them into the proper code within the context of real-time world applications (e.g., multiple time signatures, tempo maps, changes to the duration of the host DAW song).

My capture code deals with all of these problems—but we can't play them back!

I'm not literally asking these questions—just describing what I'm thinking the playback code should address given my (and other's. including I think your own) questions about this tantalising topic.

How do we learn what tempo and time signature changes are in the host sequence? The only way I can see to do this is to play the entire song, and capture every time signature and tempo change. But that won't work because (among other things) the user may change them.
Given that the position data of the MIDI Player seems to be a float from 0.0 to 1.0, how would I know where I am on the timeline if I don't know all the time signature and tempo changes?
How do we store (e.g., Flush) and access these changes in the MIDI Player's sequence—literally by creating the corresponding MIDI events? (Will that even work, considering the capture is in real-time?)
Everything is stored in ticks, but still—maybe it's just my OCD, but it's just wrong to create a sequence with a specific time signature and tempo when they don't apply to the song. For example, the sequencer requires us to pre-determine a fixed length for the sequence—but without knowing the tempos and time signatures, what values should be used? (I see Chris answers this, but my tiny mind struggles to apply it here.) The user will inevitably extend the song length in the DAW.
Once the event list is flushed into a MIDI player sequence, how do I synch the clocks? (I see this is explained in the thread, but I'm a bit lost within the above context.)
Once the clocks are synched, I set my transport callbacks to start and stop the MIDI player when the host does so—will the event positions of my HISE-based sequence magically play back according to their time-stamps? (E.g., if the use goes a specific point on the DAW's timeline, and presses play, will HISE's MIDI Player play the correct notes at right time?)

Thank you, as always, all.

Christoph Hart

@clevername27 I think the most important point you're getting wrong is that the tempo and the time signature do not matter at all for the MIDI player if it the data is stored in ticks - it's the DAW's job to change the playback properties and propagate it to the MIDI player and if the player is synced to the DAW clock, then it will handle tempo changes, position changes (seeking) and even DAW loops correctly.

will the event positions of my HISE-based sequence magically play back according to their time-stamps?

Yes :)

ustk

@Christoph-Hart After having the above double triggering issue fixed, I wonder how one would approach automatic file change when reaching the end of the current sequence?
I can't find a reliable method to perform a synced sequence change...
I tried using setOnBeatChange and getPlaybackPosition, and computing the sequence length from the ceiled Numbars times the Nominator to count the beats but it behaves unreliably...

Another one, when not having the endOfTrack event, the midi player overlay draws the content ending at the last noteOff.
So in the end, I wonder if this shouldn't be handled by Hise, instead of rounding the bars in script?

clevername27

@Christoph-Hart Thank you - understood.

gorangrooves

@Christoph-Hart I want to provide further info regarding the bug @ustk demonstrated in the video above, regarding the double triggering of the same note when a MIDI file loops.

The dual kick notes (#36/C1) happen on beat 1 of the 2nd play through the loop, when the tempo is set to 120bpm and 160bpm.
If the tempo is set to 80bpm, the dual kick note plays on beat 1 of the 4th repeat.
If the tempo is set to 240bpm, the dual kick note plays on beat 1 of the 3rd repeat. Other tempos seem OK.

I don't know if the issue is present on any other notes, but it is definitely there on C1.

And just to clarify, @ustk did not fix the bug, as it may seem from his previous answer.

ulrik

@ustk said in MIDI Player/Transport bugs & info requests:

A strange thing the files don't contain an EndOfTrack meta-message since it is stated by the midi normalisation and they are exports from different DAWs... I couldn't find a tool to show me what's aside from the on/off notes and controllers.

I found this tool (MacOS), and opened one of you midi files

Synalyze it

It will show the end of track info

Did you manage to get Hise Midi Player to read the End of track data?

ustk

@ulrik Thanks mate! So I tried and the EndOfTack event is present in all the files I have...

@Christoph-Hart Why is the NumBars metadata always throwing a length that corresponds to the last note off?
Bug or misunderstanding?

Christoph Hart

@ustk because the JUCE Midifile parser seems to ignore that value.

ustk

@Christoph-Hart The note that is triggered twice when looping is still not resolved.
Here's the related post that demonstrates the issue: https://forum.hise.audio/topic/7311/midi-player-transport-bugs-info-requests/21

gorangrooves

@Christoph-Hart I was chatting with @ustk about workarounds for the issue where HISE shortens MIDI files by a beat, when playing them once. 4/4 becomes 3/4. (It only plays correctly when looping).

Here is the thing: even if I were to modify and re-export all of my MIDI files (several thousand) to have a note off at the very end of a MIDI file, it would leave countless regularly-exported MIDI files by other users not properly-playable by a HISE player.

Keep in mind that simple players like Windows Media Player will play all MIDI files with the correct length, so this is really a HISE bug that I strongly feel should be resolved in the source.

Do you think you could please examine how HISE handles playback of MIDI files (single play, not looping) and provide a fix so that the entire length of a bar plays fully?

ustk

@gorangrooves So this has been fixed here:
https://forum.hise.audio/topic/7581/still-trying-to-make-sense-of-tempo-sync-and-midi-loop-issue/19

gorangrooves

@ustk that's fantastic news! Thanks @Christoph-Hart

Apologies for me being a bit late to the party

MIDI Player/Transport bugs & info requests

16

1.8k

10.3k

90.0k