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.
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.
Since sub-millisecond resolution could be useful, is there a way to implement the micros() function from Arduino as well?
I’m thinking about porting a real-time MIDI Note or Clock jitter analyzer code to the e1.
Which basically calculates the interval between two timestamped Note or Clock messages, and stores these intervals values into a circular buffer to run some statistics upon it and display those datas. Mean, median, mix, max, variance, standard deviation, you name it…
Grabbing those stats is really interesting to me: not all MIDI devices or software comes equal when it comes to accuracy and stability, sometimes depending on the BPM.