I need to be able to establish the relative time difference between when a specific MIDI message arrived and when the timer ticked.
I want to run code if the relative time difference is above a threshold.
My current approach would be to have my own uptime counter and increment it when the timer ticks.
When the MIDI message comes in, I would store the value of my uptime counter and then compared to that stored value in my timer tick callback.
This would work but my precision would be limited to the period of the timer.
If however there would be an uptime timer (in milliseconds preferably) that is exposed in Lua then I could use that to programmatically establish when things happened relative to each other.
Yeah I was thinking I’d need this for relative time/deadline scheduling as well at some point.
A monotonically increasing milliseconds since boot would do the trick.
is os.clock() implemented in the Electra One version of LUA?
(no devices handy to check this)
The documentation indicates that api in LUA only provides second level granularity.
Plus usually those date time libraries are not guaranteed to be monotonically increasing so things can step backwards (often caused by NTP) which then causes bugs with timing code. This would likely happen a bit if it corrects when you connect to something like a time synced computer.
Milliseconds since boot though monotonically increases so you can always diff two to know the relative time diff or schedule for a future time without having it slip more into the future.
E1 internally runs a hardware timer at 1 msec intervals, and it keeps track of the number of milliseconds since boot. I’m considering making this time information accessible through a function similar to the Arduino-style
millis() . After reviewing the existing Lua functions, it appears that none of them precisely match this functionality. Therefore, repurposing something like
os.clock() (which measures time in seconds) or
socket.gettime() might be confusing…
You could just create your on function, something like
e1.uptime() that would return an unsigned integer with milliseconds.
The available bits for the counter matters though.
If my math is correct then:
- a 16 bit counter would overflow in about 66 seconds
- a 32 bit counter would overflow in about 50 days
- a 64 bit counter would overflow in about 600 million years
I would be fine with a 32 bit timer but if someone puts their E1 to sleep instead of turning it off then the counter could potentially overflow and cause weird issues.