USB midi clock input jitter correction

Discuss or suggest new features here.
Please do not report bugs here, use the "Bug Reports" forum instead.
Post Reply
MPrinsen
Posts: 92
Joined: 01 May 2023, 13:42

USB midi clock input jitter correction

Post by MPrinsen »

In some cases, it is more desirable to just use the DAW’s own built in midi sync output, especially when dealing with devices that have a high clock latency: instead of adding a high audio latency to the whole project using negative track latency (through u-sync or manually in your DAW), your DAW can just start outputting the clock earlier than actually starting its own playback.

However, as you all know, a DAW will not send a very tight clock signal usually, especially with higher buffer sizes. That’s why audio sync and u-sync are invented.

I was thinking that it would be really nice to be able to use the DAW’s own clock output, send it to the Nome and let the Nome correct the input clock jitter, then send a more stable clock to its own outputs.

Of course, this will have some downsides:
- less tight than audio sync or u-sync
- it will probably need a buffer to correct the jitter, adding some latency (but you can offset the clock to correct for this)
- it will react to tempo changes a bit slower

But it will have some upsides compared to audio sync and u-sync:
- possibility to offset the clock without adding (audio) latency to the whole project
- it may even allow to send separate clock signals for both midi outputs of the Nome with their own clock offset
- possibility to send SPP (if the DAW supports that) and maybe other midi clock related messages I’m not fully aware of (maybe MTC?)
- even easier setup, no need for a plugin or audio pulses
- probably still tight enough clock for most people’s needs

I guess the most ideal way to implement this is to have a buffer size parameter to determine how long the buffer of incoming tics has be to calculate the mean distance between the tics before outputting the corrected clock. So everybody can set this to taste, as a longer buffer allows for tighter clock (if the tempo doesn’t change), while a shorter buffer will make the Nome react quicker to tempo changes and adds less latency.

Let me hear what you guys think :) I think it would be a really good solution for Roland TR-1000 users (myself soon included), as it has a very high clock latency (>50 ms) with certain settings in its current firmware.
Post Reply