-
-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increasing clock precision #257
Comments
I'd be curious to see your implementation, I implemented that one point but it affected the performance a lot(CPU spiked), I have a slow computer, did you notice that it affected the performance a lot? |
I haven't done a performance test yet, but I will. I also want to test the AudioContext clock as an alternative. My idea looks pretty similar to this blog post, but I will investigate more and, hopefully, share a proof of concept if anything good comes out. |
@giohappy hey did anything good come out of this? |
@boonier I didn't have the chance to move this forward. |
Testing the MIDI Clock with Reaper and Bitwig I've noticed that it has jitters and it's slightly offest. E.g. 110 bpm results in values jumping around 110.3/110.4 inside the DAWs.
This is expected when
setInterval
is used, even if the main clock ticks inside a WebWorker.Have you ever considered a solution where the clock ticks on the base of time measured with
performance.now()
?A setInterval callback might be set to run, let's say, every 5ms, but a time "integrator" could use
performance
time to decide when a tick should actually trigger.From my tests (with an infinite loop in my case) using
performance
to decide when to send the MIDI clock pulses I can get a stable and reliable bpm in my DAWs.The text was updated successfully, but these errors were encountered: