We Keep Coding

setTimeout triggers too late in MIDI.js

I'm using MIDI.js to play a MIDI file with several musical instruments.
The following things execute too late, how can I fix that?
First notes of the song. Like all notes, they are scheduled via start() of an AudioBufferSourceNode here.
MIDI program change events. They are scheduled via setTimeout here. Their "lateness" is even worse than that of the first notes.
When I stop the song and start it again, there are no problems anymore, but the delay values are very similar. So the delay values are probably not the cause of the problem.
(I use the latest official branch (named "abcjs") because the "master" branch is older and has more problems with such MIDI files.)

That is how JavaScript Event Loop works.
Calling setTimeout ... doesn't execute the callback function after the given interval.
The execution depends on the number of waiting tasks in the queue.
... the delay is the minimum time required for the runtime to process the request (not a guaranteed time).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop#zero_delays
Instead of setTimeout() you can use window.requestAnimationFrame() and calculate elapsed time for delay by yourself.
Window.requestAnimationFrame() - Web APIs | MDN
The window.requestAnimationFrame() method tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation before the next repaint. The method takes a callback as an argument to be invoked before the repaint.
... will request that your animation function be called before the browser performs the next repaint. The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers
https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
performance.now() - Web APIs | MDN
https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
In our situation, we don't want to do any animation but want to just use it for a better-precision timeout.
const delayMs = 1000;
const startTime = performance.now();
function delay(func) {
const delayStartTime = performance.now();
function delayStep() {
// Run again if still elapsed time is less than a delay
if (performance.now() - delayStartTime <= delayMs) {
window.requestAnimationFrame(delayStep);
}
else
{
// Run the delayed function
func();
}
}
// Run first time
window.requestAnimationFrame(delayStep);
}
// Trying `setTimeout()`
setTimeout(() => doSomeJob('setTimeout()'), delayMs);
// Trying `delay()`
delay(() => doSomeJob('delay()'));
// Function that we'd like to run with a delay
function doSomeJob(marker)
{
const elapsedTime = performance.now() - startTime;
console.log(`${marker}: Ran after ${elapsedTime / 1000} seconds`);
}
If you run it many times, you'll see that delay() is pretty much all the time better than setTimeout(). The difference is very small because there is nothing else happens on the page. If there will be something intensive running, setTimeout() should demonstrate worse "precision".

Do NodeJS setInterval()s queue up?

There's a classical problem with setInterval() in browsers - if some JS code or other browser process takes too long to complete, several callback invocations might get "backed up" and you suddenly end with your callback executed multiple times in quick succession.
Often this is not what is desired when setInterval() is used. It's a typical use case when you want AT LEAST some interval of time to pass between invocations. The workaround to this is to use setTimeout() instead and only schedule the next invocation when the previous is completed.
This works well but also is extra code and might be confusing for someone who does not understand the issue.
I know that NodeJS works differently than browsers, but I cannot find any information on this particular aspect. Does NodeJS also exhibit the same behavior, or does it guarantee a minimum time between invocations when using setInterval()?

Looks like it.
start = () => {
console.log(Date.now(), 'interval started');
setInterval(() => console.log(Date.now(), '-'), 1000);
}
busy = (n) => {
console.log(Date.now(), 'busy started');
for (let i = 1; i < n; i++) Math.sqrt(i, 7);
console.log(Date.now(), 'busy done');
}
start();
busy(1e10); // this takes a while; nothing is printed, because this keeps the node.js thread busy
Output:
1642469880773 interval started
1642469880776 busy started
1642469888272 busy done
1642469888272 -
1642469889273 -
1642469890274 -
Note the long gap between busy start and done, and how no backlog of interval callbacks seem to follow.

Invoke a function after the time changes

I'm curious if you can invoke a function after the time changes?
For example invoking a function after the minute changes maybe something like this:
onMinChange(()=>{console.log('the minute has changed!')})
Note:
I do not mean waiting for a minute to invoke a function like this
setInterval(()=>{console.log('the minute has changed!')},60000);
there's a difference between
✓ invoking a function after the minute changes (Current time 2:30:05, invoke function at 2:31:00 )
&
X waiting for a minute to invoke a function (Current time 2:30:05, invoke function at 2:31:05 )

There's nothing built into the web platform that will do this (nor, I think, Node.js's standard library). The closest you can come (without some third-party lib) is to get the time, calculate how long it should be until the next minute, and then use setTimeout to schecule a callback. If you want it repeated, repeat as necessary.
Here's an example:
const MINUTE_IN_MS = 60000;
function callNextMinute(fn) {
const now = Date.now();
let next = now / MINUTE_IN_MS;
const ceil = Math.ceil(next);
if (ceil > next) {
next = ceil;
}
return setTimeout(fn, (next * MINUTE_IN_MS) - now);
}
function tick() {
console.log(`New minute! Time is ${new Date()}`);
callNextMinute(tick);
}
console.log(`Started at ${new Date()}`);
callNextMinute(tick);
There, the margin of error is ~10 seconds.
Beware that:
That kind of recurring execution can have an adverse effect on battery life of mobile devices.
Timers are slowed or even stopped for tabs that aren't the active tab in many browsers, so you may well miss the minute if the tab is inactive.

You can achieve behaviour like this with the npm package cron.
var job = new CronJob('* * * * *', function() {
console.log('You will see this message every full minute');
}, null, true, 'America/Los_Angeles');

How do you debounce a function after the first call?

I am trying to make a function similar to debounce, except I want the debounced function to be called immediately after the first call and all calls after the first call within the debounce time limit to be debounced. For example, if the function is hooked up to a button, and you rapidly and repeatedly click it 10 times, the function gets called on the first press and gets called a second time after x milliseconds have passed since the tenth press.

Pure JavaScript processing:
Requiring a repeated call within the "debounce" period to be called in addition to the first call adds a complication that can be addressed using a timer in addition to timestamps to make immediate calls if possible.
However, because calls to a function may be delayed, it is not always possible to return a value from the function to the caller in real time.
The following concept code
calls the process "lock" in the sense of locking out calls in a predefined way.
returns undefined to all calls without implementing call backs to allow a caller to tell if its call was actioned or not, or to retrieve a return value;
When a call is made after a lockout period within which addition call attempts were made, the actual arguments used are to place a delayed call are those supplied by the most recent call attempt.
function CallLock( toCall, lockout) {
let argv;
let lastCall = 0;
let timer = 0;
function recall() {
timer = 0;
lastCall = Date.now();
toCall(...argv);
}
return function( ...args) {
let now = Date.now();
if(timer == 0) {
if( now >= lastCall+lockout) {
lastCall = now;
toCall( ...args);
}
else {
argv = args;
timer = setTimeout(recall, lastCall+lockout - now);
}
}
else {
argv = args; // use most recent arguments
}
}
}
// test CallLock
let start;
function demo( msg) {
console.log( "demo('%s') called. Time is %sms after start", msg, Date.now() - start);
}
let lockDemo = CallLock( demo, 1000); // 1 second lockout
start = Date.now();
lockDemo("call 1");
setTimeout( lockDemo, 200, "call 2");
setTimeout( lockDemo, 400, "call 3");
setTimeout( lockDemo, 1800, "call 4");
Test code uses a 1 second lockout time. Note that timer delays are inexact and Date.now() rounds to the nearest millisecond. The expected results are
call 1 is made synchronously and will show a start time of 0 or 1ms.
call 2 is never actioned - its arguments are not used.
call 3 is actioned, but delayed until shortly after the first call lockout
call 4 is actioned, but also delayed because the lockout period from when call 3 was actioned is still in effect.

Sounds like throttle. check this article for difference between throttling and debouncing. if throttle isn't what you need, then you should implement what you need from scratch (and adding more explanation for the details).
Edit:
So, Yes, It is not throttle; It is debounce with invocation on leading edge in lodash;
_.debounce(yourCallback, 100, {
'leading': true
})

I would suggest don't go for debounce. The older debouncing technique relies on setTimeout which is not perfect. Instead try to make use requestAnimationFrame which has in built support for the next trigger for Dom visual states change.

Limiting NodeJS setImmediate

I'm trying to have a loop in my NodeJS Environment that will execute 30 times a second (Based on a fixed variable). I've been told that setInterval and setTimeout isn't the way to go in terms of NodeJS as process.nextTick and setImmediate are available to comply with the I/O queue in NodeJS. I've tried using the following code (setImmediate):
var Physics = {
lastTime: (new Date().getTime()),
upsCounter: 0,
ups: 0,
init: function() {
Physics.loop();
},
loop: function() {
var currentTime = (new Date().getTime());
Physics.upsCounter += 1;
if((currentTime - Physics.lastTime) >= 1000) {
Physics.ups = Physics.upsCounter;
Physics.upsCounter = 0;
Physics.lastTime = currentTime;
console.log('UPS: ' + Physics.getUPS());
}
setImmediate(Physics.loop);
},
getUPS: function() {
return this.ups;
}
};
My problem is that Updates Per Second (UPS) is over 400,000, rather than the required 30, and I was wondering if there was any way to limit it down to this number, or an alternative loop structure. Thanks

I've been told that setInterval and setTimeout isn't the way to go in terms of NodeJS
Of course they are when you need a timeout or interval!
setImmediate/nextTick are immediate, which is not what you want. You cannot limit them, they are as fast as possible by design.
If setInterval is not accurate enough or drifting, then use a self-adjusting timer.

You should go ahead and use the setInterval or setTimeout method, but make sure to unref them so they don't hold up the process that would otherwise exit, unless that timer is the main execution for the program.
see: Node Timers API Documentation
javascript
var t = setInterval(myMethod, 100);
t.unref(); //the timer t will not execute if the rest of the program is ready to exit.