two minutes later - touched nothing
lower recording drifted further
Odd , as above, I did a 45 minute test with octatrack and against ableton timeline ( unsymcād) ā¦ didnāt budge at all.
I used good old midi din 
Itās interesting OP was with e-rm multiclock too.
Youād expect it to help rather than hinder the situation?
Btw what zoom level are you at, what do the bars represent in time values ( milliseconds)
Also what happens on a longer test - say 15 minutes, is there a continual drift?
let me do some further testing. It is not the E-RM Multiclock. That i can 100% say. I have made many test in the past. The Multiclock works fine.
One bar is 1/8192 bars = 0,244 ms.
1 Like
yeah, I wasnāt implying it was the erm multiclock, Im aware of its stablityā¦
rather just it interesting that it coincides with the OP.
at the end of the day, midi clock should be just āmidi clockā (assuming we are all using DIN)
hmm, so gone from 2x.244, so lets say 5mS , to 8x244, ~2000ms, so nearly 2 secondsā¦
thats in line with OP as well, as thats obviously audible.
out of interest was the DAW also clocked?
(not that it should make any difference really, we are just looking at audio traces, which assuming no warp are constant.)
what would be interesting, as I mentioned to @sketcherone , is this a slow constant driftā¦ or does it suddenly ājumpā , as if itās catching upā¦
this might happen, if for some reason midi clock messages are delayed (eg in transport/processing) or worst still dropped.
do you have another way to clock the hapaxā¦ to see if its doing the same thing?
I guess, we could try usb from a dawā¦ (but on some computers, thats unreliable for any sequencer)
@sketcherone , did you get any further on the cause of your issue?
no no ā¦ the Daw (Ableton Live) is the master for the Audiosource of the E-RM (using the e-rm plugin)
(if Live is slaved it jitters quite a bit)
I just ran the Machinedrum standalone and it jitters around 1ms (few single shots up to 2 ms! )
I will switch to Digitakt as sound source . But anyway iām not searching for jitter (as long it is in the 1ms range i donāt mind to much) - i was about to search for offset of like 1 /16th or a whole beat
the Digitakt doesnāt jitter on itās own (nothing i can measure)
it also doesnāt jitter when clocked by the Multiclock (nothing i can measure)
the DT sequenced with HAPAX jitters upto +/- 0,5 ms (on average i see more like +/- 0,25 ms)
I think itād be good to break the problem down a bitā¦
the first step Iād do isā¦
a) Live ā Hapax ā¦ direct USB
just get Hapax to send a midi note back to Live and record that midi.
see if it drifts. we are looking for drift not jitter ā¦ I think
but you could look for jitter too.
USB is not perfect , and better/worst on some setups - but in my setup at leastā¦ I find its fineā¦
Ive ran a 2 min test, and saw sub 1 mSec variance
btw: I cut off the 1st bar, to let the clocks āsettleā and test is at the default 120bpm
(Im doing a longer test now)
b) do the same but put e-rm in the mix.
Id expect the same, but just less jitter
if these show no drifting, then this would suggest perhaps the clock inside Hapax is actually ok.
(which is what Ive seen so far)
but rather the midi being sent to the digitakt/machinedrum is somehow being affected?
I assume you are not clocking thru the hapax for theseā¦ rather just sending midiā¦
(*) as youād go thru the e-rm if you needed clock there.
this seems like a possibilityā¦ given that @Loz , noticed issues with midi thruā¦ so perhaps generally midi output is being affected in some scenario.
(might be why my tests with using cv/gate didnt show issuesā¦ though my live test so far is looking fine too ā¦ though thats usb not din!?)
first test:
E-RM Multiclock ā Hapax ā Digitakt - Hapax not touched
jitter +/- 0,5ms (clearly caused by Hapax as DT doesnāt jitter with Multiclock)
after 11 mins record no drift or offset
second test:
E-RM Multiclock ā Hapax ā Digitakt - Hapax used
copy /pasted the pattern 8 times - timing still stable
1 Like
ok, so you are talking sub millisecond jitter?
not an issue with drift thenā¦
if we were talking audio samplesā¦0.5ms at 48000 SR is only 24 samplesā¦
thats a pretty small shiftā¦
But, Iām confused about how that relates to you 2 min test, where you said it varied by nearly 2000 mS, or 2 seconds!
did you remove the initially start offset in your previous testā¦ I find one or two bars is usually enough to let it settle.
thats pretty much a midi clock issueā¦ you need a certain number of clock ticks to alignā¦ so beat 1 is always going to be a bit off. though again , 2 seconds is a lot!
just completed a 16:30 min test with Live ->usb ā hapax. (donāt have a multi clock)
no drift, my jitter seems to be +/- 0.2 mSec - that be about +/- 10 samples @ 48k
is that within limits?
I donāt knowā¦ weād need to talk to Squarp about how frequently midi is processed, and sent outā¦
not totally relevant but perhaps gives context of what -0.2mS means
192 ppqn is ~125 samples at 120bpm/48k, so 10 samples jitter would be < 1/10th of resolution.
personally, Id say +/- 10 samples is acceptableā¦ from memory, of seeing other tests of sequencers / grooveboxes thats is pretty good . (someone on Elektronauts recently posted some comparisons)
Please lets focus here on the Drift and sudden offset of 16th or whole Beats issue. The jitter of the Hapax is fine.
The initial start offset is not happening if you are working with the E-RM Multiclock , as it already needs 1 Bar to start (to allow negative offsets)
In my first test did this morning something led to an offset/drift of of 11/8192 = 2,684 ms in only 2 minutes.
Currently iām working on to reproduce it, but the Hapx is as of now not drifting.
yes, I was focusing on drift, ā¦ thats why longer tests are better.
but as of now, Ive not seen drift at all on these longer tests.
either from din input (from octatrack) or usb (from Mac/Live)
(I only commented on jitter, as you mentioned it 
)
as already mentioned, I think the thing to look for is:
does it occur as a JUMP in the offset (I think OP said they had seen this) , rather than a drift.
once that offset occurs , does it stay (ieā¦ it not a form of jitter)
(so in your first test, look for when did that offset get introduced, and how quickly)
if that is the case, then Id say somewhereā¦ midi clock messages are either being severely delayed, or droppedā¦ under some circumstances.
this could mean, that you could do long tests and never see it, or be really unlucky and run a quick test, and suddenly it occurs.
(id say 2 seconds is a very big jump, so in that case, id be surprised if it wasnāt a few smaller jumps)
the OP thought this coincided with chaining FX, in particular Swing, though my tests didnāt show that this caused a problemā¦ but thatās not to say its impossible.
if its some āprocessingā issue, then this might be why we canāt see if in simple tests letting it run.
since the clock is generally stable, but something is āinterruptingā it under certain situations.
just had a break of 45 mins and let it run ā¦ there is not the slightest sign of drift.
so what we know:
-
no issue mit the midiclock-source (multiclock in my case)
-
no extreme /unusal jitter
-
no drift
-
something while using the Hapax is causing a delay at a certain point
sorry we weāre doing wrong math:
ā¦ thats 11 bars of 0,244 ms = 2,684ms = 0,0027 seconds
i did something now , all notes are suddenly delayed 5 ms
i edited a pattern , added some notes with trig conditions and roll + used live playmode
i can see that the playhead is now not moving smoothly anymore
1 Like
lol good point! ā¦ im getting my . and , mixed up
(and though from the UK, I live in EU so shouldnāt fall for this )
k, 0.244ms , sounds a bit more than jitterā¦ but Id be good to check the difference from (e.g) bar 3 vs 11ā¦ just to remove doubts around offsets.
but your latest tests sound much more promising ā¦
cool, if you can get a reproducible scenario that will really helpā¦
its also good if its a āsuddenā delay of 5ms, this again, points to the jump, rather than drift as Ive suggestedā¦ and what the OP saw
interesting what you say about playhead not moving smoothlyā¦ sounds like there might be a cpu issue, perhaps its not ālikingā something ?
(did you check cpu load, its in the settings info tab iirc)
i told that the support alreadyā¦ they were aware of the issue ā¦ iāll check CPU usageā¦
one thing that definitely bringt the pattern out of sync is playing with the start/end points and then reseting them to normal (1-16).
My pattern is now half a bar offset.
Second try now itās offset 1 Beat.
If switch patterns it gets back in original sync.
thereās no relation to CPU usageā¦ i see here 7-8%
but when i add several notes with trig conditions the playhead starts to stutter badly - but this doesnāt have any influence on the actual playback of the notes
but i have now the delay of 5ms back
.
.
.
i thin k i give up for today ā¦ some operation is causing delay of 2ms -5 ms from certain point on ā¦ but to track that down is really time consuming.
I have now a very badass beat runningā¦ maybe i make some music out of it
ā¦ i literally just finished writing the lines above, i added Chance FX on slot 8 and suddenly there was a huge audible jump and now the pattern is offset more than 1 beat long
==============================================================================
so the final result from yesterday:
- adding Chance FX has a high probability of generating a bigger time offset (if other FX do the same needs to be tested)
- adding trig conditions and roll has a very high chance of adding a delay of 2 -5ms
i think those points led to the screwed up timing i experienced the day before. In this state the Hapax is only of limited use for me. I hope these issues will be fixed soon.
1 Like
Just reading through this thread and wondered if you (@verstaerker) are still experiencing these issues? I noticed reading through the update notes that there were improvements to midi clock bugs around March/April time this year, just after your last post on this thread.
Are you still using the ERM as master clock or are you using Hapax/Ableton/something else as the master clock?
Thanks!
there were 1,2 earlier updates that dramatically improved the situation.
For me itās stable now.
Iām using the E-RM Multiclock as master lock. Nothing else, never.
The only thing is, iām still missing the autosync feature of the Pyramid.
1 Like
Thanks for your response, thatās really good to hear.
Is your ERM connected to the Hapax directly via DIN cable? So, ERM out to Hapax in?
Iām considering buying a multiclock or just a simple midiclock and was wondering how best to connect it.
For context, the Hapax needs to connect to a iConnectivity mioXL, where all my other hardware is connected via a mix of DIN and midi host connections, so the Hapax routes all its midi signals via a single USB host cable to the MioXL.
Hopefully that makes sense.
Thanks again