![]() I assume you are not clocking thru the hapax for these… rather just sending midi… If these show no drifting, then this would suggest perhaps the clock inside Hapax is actually ok.īut rather the midi being sent to the digitakt/machinedrum is somehow being affected? Ive ran a 2 min test, and saw sub 1 mSec varianceītw: I cut off the 1st bar, to let the clocks ‘settle’ and test is at the default 120bpm ![]() USB is not perfect, and better/worst on some setups - but in my setup at least… I find its fine… we are looking for drift not jitter … I think Just get Hapax to send a midi note back to Live and record that midi. I think it’d be good to break the problem down a bit… I guess, we could try usb from a daw… (but on some computers, thats unreliable for any, did you get any further on the cause of your issue? This might happen, if for some reason midi clock messages are delayed (eg in transport/processing) or worst still dropped.ĭo you have another way to clock the hapax… to see if its doing the same thing? What would be interesting, as I mentioned to, is this a slow constant drift… or does it suddenly ‘jump’, as if it’s catching up… (not that it should make any difference really, we are just looking at audio traces, which assuming no warp are constant.) Out of interest was the DAW also clocked? Thats in line with OP as well, as thats obviously audible. ![]() Hmm, so gone from 2x.244, so lets say 5mS, to 8x244, ~2000ms, so nearly 2 seconds… Rather just it interesting that it coincides with the OP.Īt the end of the day, midi clock should be just ‘midi clock’ (assuming we are all using DIN) Yeah, I wasn’t implying it was the erm multiclock, Im aware of its stablity…
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |