im offsetting midi clock to make up for latency and it drifts over minutes. i stop and start and its tight again. anybody else experience this?
and can it be a receiving unit? it could be my raspberry pi non realtime kernel
im pretty sure now its not hapax but i figured id ask whoever knows more than i
to my surprise, this turned out to be the polyend tracker which had a big offset that i dont remember putting there. it drifts over time but doesnt seem to when there is no offset. hapax offset of clock on its buss works great. these things always require debugging.
sorry hapax, im mistaking you for inferior equipment. i knew it wasnt you in my heart lol
2 Likes
so, sorry but im going to reopen this with further explorations by syncing my tracker to my tr6s, hoping that i see the same problem with drift. this should either point me towards tracker as the source of my issue or away from tracker and back towards hapax. ill post up the results asap. im rooting for hapax since im in love with it and dont want there to be an issue originating with hapax.
and i suppose that my raspberry pi could still be the source of my problem. im not sending sync to it however so if a non-realtime kernel can create these kinds of problems, id love to hear anyone with knowledge speak up, in the absence of that i guess ill take the step of installing patchbox os which has a realtime kernel.
its looking more and more like the raspberry pi at this point so the next thing will be to install patchbox os for the realtime kernel. i talked to my buddy who says he experienced the same thing. right now, my tracker is following the tr6s just fine more than 5 minutes in. so im closing this again haha sorry to keep you all suspended
when i say tempo drift that characterization is inaccurate. im not sending midi clock to my rpi5, im only sending midi note commands. i am sending midi clock to a polyend tracker and this contrasted with audio from the rpi5 make it sound like there is drift related to midi clock when its actually the latency of the rpi5 moving around due to a non-realtime kernel.
one more post after i install patchbox with its realtime kernel and try this again.
so that was down to the kernel. ok now im running windows 11 on the same device and its working perfectly and i can run paid stuff. it natively runs x86 stuff on rpi5 with no special conversion, just install the native x86 stuff, get asio4all and away you go! tiny and cheap!
having a real time kernel helps with the drift but the real cause is that the teensy (running dirtywave m8 headless) passes audio to the host rather than directly outputting it. DIYers are now putting a DAC on the teensy, avoiding this problem altogether. hapax was never the issue, it just took me a while to work out what the actual issue was. my apologies again to hapax which is my favorite sequencer. of all time. the offset capability is simply amazing!
2 Likes
Been following the journey and heard you mention the offset in another thread; how are you measuring the diff and/or is there a way to accomplish the analysis w/o a computer. I have a mordax data if that would work
by ear. i make simple test pattern with output to several different targets with separate latencies. it gives you a good idea whats really going on. once its all perfectly lined up, everything sounds like its coming from the same source, and potentially hits harder! phase problems reveal themselves easy with everything lined up…
whats really interesting is that slight misalignment can sometimes make your bass patch more groovy. there is definitely a sweet spot.
1 Like