Input Latency upper bound

[smilingthax]

When Recording MIDI Events via MIDIInput.onmessage, when can I be sure that no more Events with timeStamp < t0 will be emitted?

e.g.:

... onmidimessage = (ev) {
  if (ev.timeStamp < stopRecordingAt) {
     // ... store event
  }
};

setTimeout(() => {
    console.log('Stopping Recording');
    stopRecordingAt = performance.now();
    // PROBLEM: can't `processStoredEvents(...)` just yet, because there could still be
    //                    midi events pending with ev.timeStamp < stopRecordingAt ...
}, ...);

When there are regular Midi Clock Messages on the input, it would be sufficient to wait for the next Clock Message to occur, but this doesn't cover the general case.

Idea:

• setTimeout(... , 0) (or similar) to run processStoredEvents() function after the currently running JS context has exited, so that the event loop has a chance to dispatch all pending events. But this will only work reliably, when the midi timeStamps are assigned in such a way, that any event with timeStamp < now is immediately available to be dispatched (i.e. when a browser uses a separate midi input thread, it MUST make sure, that any midi events timestamped there with t0 < now will be dispatched before the setTimeout function is executed).

Does the current Web MIDI Standard guarantee this?

Otherwise, these are my thoughts of how the standard could be extended:

• it guarantees a fixed upper latency boundary (e.g. 100ms), during which the events are surely delivered.
  This does not seem feasible, as a running JS context can delay the execution of onmidimessage arbitrarily.

• there is some way to request a "synchronisation" on the input, i.e. onmidimessage is executed with an "empty" event that contains the "current input timeStamp" (and there is some ordering guarantee, i.e. midi events are delivered with monotonically increasing timeStamps).

• MIDIInput is extended to contain the "current input timeStamp", similiar to the synchronisation case.

What do you suggest?