clock.sync to values less than 1 can cause rapid-firing (v4.0.3)

[dndrks]

(report came in thru support, from which i built a generalized test case!)

test script, essentially print the beat with every sync

```lua function init() clock.tempo = 90 div = 1 start() end function start() if clock.threads[test_clock] then clock.cancel(test_clock) end test_clock = clock.run(step_through) end function stop() clock.cancel(test_clock) end function step_through() while true do clock.sync(div) print(clock.get_beats()) end end ```

results

note that div = 0.5 is totally stable!

div = 1 ✔

7254.0
7255.0
7256.0
7257.0
7258.0
7259.0
7260.0

div = 0.9 ✔

> start()
27.0
27.9
28.801
29.7005
30.6
31.501
32.4005
33.3
34.201

div = 0.8 ✖️

268.981
268.9825
268.984
268.9855
268.987
268.9885
268.99
268.9915
268.993
268.9945
268.996
268.9975
268.999
269.0
269.6
270.4005
271.201
272.0

with this case, it seems like the clock slips and plays catchup -- once it lands on a whole beat, the resumes continue for a while at the specified div. but, they quickly lose track again.

please lmk if i can provide any additional testing or repro cases!

[eethann]

Thanks for the reproduction case, @dndrks, this follows my experience working with 0.4, 0.25, etc. Fractional values are helpful for things like swing, work as expected on Norns. I poked around the C source a bit but couldn't see the issue, wish I could be more helpful, I'll keep staring at it.

I am curious if there are any differences of behavior at different BPMs.