I’m not sure how sys.ms is represented, but I think it has overflowed and wrapped into negative. It’s currently returning a negative value.
updated: does appear to be signed 32-bit overflow, adding 2^31 hacks around it
You left Decker running for 24.8 days?
EDIT: Wait, no, I see what’s going on.
Native Decker computes sys.ms as a float, Web Decker takes a float from the browser and truncates it into a 32-bit integer.
I guess it shouldn’t matter if you’re using sys.ms for performance timing (duration:sys.ms - start) but it does make problems if you’re trying to divide the clock with a modulus operator.
I was using it for frame timing for the bpm.
current time - last beat > bpm gap -> send a bang
so, i just hacked it by reoverflowing to positive by adding 2^31.
i just realized it’s still not 100% correct, because i’m not accounting for the timing gap (jitter) that is getting lost due to 60 Hz quantization.
update: oh, right. it wasn’t working because the “last frame” time was never initialized - so “current time” - “last frame” will always be negative, since it’s “current time” - nil (0). that’s the real reason.
so, anyways - i don’t know if negative sys.ms is supposed to be a thing, but it certainly wasn’t expected. it’s how i usually time gaps and don’t worry about initializing the first frame time for the possibility of negative time.