How to correlate times from different MIDI interfaces?

[mcclure]

Not sure if this is a feature request, a documentation request or just a support request… but…

RtMidi gives all times as deltas, ie, time since last event. I assume (?) this is time since last event on the port that read the delta.

I find that in practice I am working with multiple MIDI interfaces (because most MIDI devices are USB now). So this would mean the delta times on the interfaces have nothing to do with each other. And somehow I have to correlate the delta times with a wall clock or audio timer, so that I can play sounds or time MIDI events out.

What methods do people use with RtMidi to convert the delta times into some form of "absolute" time that allows comparing events from different interfaces, planning output times etc?

And a feature request I'd be curious about: A friend told me that Mac OS X CoreMIDI actually correlates all MIDI events with Mach time. So that implies RtMidi already has absolute-time stamps for every event. Would it be possible for RtMidi to optionally expose these absolute-time stamps somehow on OS X? Then I could get improved performance on OS X even if I have to fall back to some kind of rougher time estimation on Windows and Linux.

[garyscavone]

I think you essentially want a way to convert delta times to some sort of common system time. It could probably be implemented with gettimeofday(), in a way similar to how getStreamTime() is implemented in RtAudio. But then you would be attempting to synchronize multiple devices / ports across different instances, which might be tricky and involve inherent device latencies.

[mcclure]

which might be tricky and involve inherent device latencies

It is tricky, part of why it would be maybe a good candidate for an RtMidi feature is RtMidi is more capable of resolving this tricky issue than user code is (because it can talk directly to OS midi services, which might expose tools for doing this)

The device latencies problem (IE: what if this device is actually just delivering every MIDI message later than you'd like) is indeed a real problem, BUT it is easier for user code to address that problem if it can focus only on the device latency problem without having to juggle other potential types of latency (for example latency introduced by RtMidi or the OS)