https://jonasth.github.io/
Anyone with good temporal and spatial abilities "logic", that can correct "my scheme to correct the note time", "check URL for realtime, animationtime and notetime"

function STARTPLAY(){
if (keepGoing) {
stopRec=setTimeout(STARTPLAY,copyEv[playPos]);
//While still notes
if (playPos<copyEv.length) {
//***THIS CODE WILL CORRECT, THE FUTURE TIMING OF NEXT EVENT IN THE FUTURE
//The realtime that passed is performance.now()-browserLoadTIME
//The scheduled time is the note timings passedTime=copyEv[playPos]+passedTime;
//Realtime-scheduledtime is our latency.
//calculate latency=performance.now()-browserLoadTIME-passedTime;
//calculate new position copyEv[playPos]=copyEv[playPos]-latency;
passedTime=copyEv[playPos]+passedTime;
copyEv[playPos]=copyEv[playPos]-(performance.now()-browserLoadTIME-passedTime);
outportarr[outportindex].send(noteMessage[playPos]);
playPos++;
if (echo && mode=="Play"){
pianoKeypressOut();
}

} else { stop();}
}
}

I think the logic is rather straight but the issue is what note to compare with realtime clock, and what note to update.

I was hoping that someone else would raise this, but no-one has.

Surely, if you add 'timing data' to a link that suffers from 'latency' (whatever that is in your specific circumstances) then the timing data would also suffer from 'latency' and be also useless? If each connected device is generating it's one timing, then you have the problem of co-ordinating the different timings? This too might be affected by the 'latency' problem you refer to?

I would have though that it would be far better to try to determine WHAT is causing the 'latency' you've got, and fix the problem at source. MIDI alone should not suffer from latency. Maybe it's coming from the OS, which is doing too many other 'tasks' at the same time. Maybe drivers (etc) are inefficient, of badly installed. Maybe the USB link is carring other (non-midi) data (like Audio data) as well, and the location of the data in the stream is interfering with the midi timing.

Maybe a piece of software that checks the data stream and compares the midi timing with the actual/real time and reports of the data passing and the time disparity might be a big help is determining what is causing the problem.

Geoff

I remove timing data from setTimout(copyEv[playPos]) which is the scheduled point in future when next note is playedup, so i do not add anything i hope. stopRec=setTimeout(STARTPLAY,copyEv[playPos]);

So this do remove time from that "future event" making copyEv(position) a smaller timing value above.
copyEv[playPos]=copyEv[playPos]-(performance.now()-browserLoadTIME-passedTime);

Copy Ev is the original distance in time to next note, then i remove (realtime-passedtime) which is the latency. And here passedtime is the "scheduled time" "by adding up notes", so the time that passed "realtime" is larger then "scheduled" time played up thus far, as one can see."The scheduled time "sum" is less then realtime during playup" because latency addup.
And that is a +latency and it will be postive value right.

Geoff i have the RT it is performance.now()-browserLoadTIME in the recursion and calculation.

So the latency=R(T)-NOTE(T) the added scheduled times, which become late cause of latency and actually is the current latency when inspecting visual.

So we want to correct when copyEv will be played up.
Now we take our copyEv-latency and get a new time for copyEv that is "shorter/closer/smaller" to previous event by remove the bulked up latency, so next call is fired/moved closer in time.

You probably did look at first example and i probably turned things around there.

Geoff what causing the latency is Javascript in itself doing things during timeOut it is not threaded and simply not suitable for realtime processing. "From what i can understand".
The javascript gurus say that every setTimeout can vary upto 5 ms before executed, so note latency in seconds add up pretty fast "if not handled".

Maybe you midi guys find my code confusing since it not quantised into ticks PPQ, but use the realtime recording values.
I will fix my code to allow for PPQ quantisation, i guess otherwise things like tempochange just become some percentage.

So my playup code do not quantise playup into PPQ intervals, it just set timeOuts, so if you want to change tempo it is basicly a percentage of the recorded time.

But the basic point of my problem is we have an array of temporal distances "time" between events. Somehow these events not played according to the R(T) clock.
So after each note played "before next note should be scheduled", we check how much was the sum of scheduled notes "drifting", relative the realtime clock.

"And right there i see a problem with my code i must compare playPos -1 with the realtime clock" that could be it. Thanks for listening to my ranting anyhow.

And then i try to remove how much it drifted.

Well in a nutshell.

Geoff, well the problem is already known javascript is single threaded and not accurate enough using setTimeout, what i try to do is find out strategies to deal with it.
Unfortunately it seem like the variable updates using setTimout and recursion is broken.

Well i solved it but isn't the full idea about setTimeout that you should avoid to do polling every x'th milliesecond.
Somehow i feel i was kicked in the nuts by javascript, i kind of reject the whole polling paradigm going on in midi and javascript.

function STARTPLAY(){
if (playPos<copyEv.length-1) {
stopRec=setInterval(playSomeNotes,5);
} else { stop();}
}
function playSomeNotes(){
REALTIME=performance.now()-browserLoadTIME;
while(REALTIME>schedTime){
outportarr[outportindex].send(noteMessage[playPos]);
schedTime=copyEv[playPos]+schedTime;
playPos++;
}
}

Jonas,

You may interested in the JR Timestamps mechanism defined in the MIDI 2.0 document, "Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol".

You can find the MIDI 2.0 specification documents here:
https://www.midi.org/specifications/midi-2-0-specifications/midi2-core/midi-2-0-specification-collection

Mike.