DT2 Delta Time Between Triggers Is Inconsistent

[ripsaw]

The playback time between each trig on the Digitakt is inconsistent, even with no micro timing present.

If you playback/record two tracks from the same project in two separate passes each pass will have it’s own inconsistencies and the two will not sound as tight when played together.

I wanted to find a way to show this on device, one that completely removes any external influence, so no midi clock jitter or interface jitter.
This also allows you, the reader, to run this test on your own hardware and see for yourself. (step-by-step instructions below.)

The TL;DR is to load a track with a short sound and place it on each trigger, then resample this track and load it into a slice machine and set a grid without using transient detection so the grid is perfectly aligned. You can then zoom in on the grid and see the timing inconsistency in playback.

Note the “offset pattern” looks different at different BPMs. These were recorded at 174

You can compare the start point of each 16th of audio to the in time grid and see the audio does not play back perfectly in sync with the grid.

Compare the above screenshots, to the following. This was identical, the same audio sample played every 16th, but this one was created in a DAW, rendered then transferred to the DT and loaded in place of the above sample.
See how each hit perfectly lines up with the slice grid lines.:

NOTE The slice positions are IDENTICAL to the above example.
Check the number in the upper right of each screenshot and compare, they match.

Instructions for following along at home, if you want to see for yourself :

1. in a new project.
2. set the bpm to 174
3. load track 1 with a short transient
4. add a trig on every step 1-16
5. go into sampling.
6. set length to 16
7. set source to track 1
8. set record start (R.START) to “Play”
9. arm the recording (ENC H)
10. hit play, then when it’s finished save the sample and assign to track 2
11. in track 2 change the machine to “SLICE”
12. get up the slice menu and “create slice grid” choose 16 slices and turn transient detection OFF
13. You have 16 slices exactly on the grid.
14. Zoom right in.
15. press > and < to cycle back and forth throughout the slices note how non of them land at the same time. (this is shown on the first image above)

Note: This timing instability is also there when:

1. Recording to a different device via the analog outs.
2. Recording to a DAW when set to midi/audio
3. Recording to a DAW with Overbridge when clocked from the computer
4. Recording to a DAW with Overbridge when not clocked from the computer
5. Recording using Overbridge standalone.
6. Recording to a DAW with the DT2 set to overbridge and acting as the interface. (useful to know it allows you to map every track inside Ableton where the plugin is limited to 16 stereo channels.)

Why is this important to know?

1. if you are individually recording tracks into your DAW via the analog out they will not sync. Think how bad this can get if you are using sidechaining, where the kick hits and the bass/other tracks ducks will be in different places on each trig.
2. recording via overbridge either standalone or via the daw needs to be done with all tracks at the same time, so they all have the same timing inconsistencies baked in. You need to know if you alter something you need to re-record all tracks.
3. if you use an audio file as a side chain trigger where you’ve shaped that in a daw, like a few bars of sculpted trigger noises that you fire off once. It will sound inconsistent beating against triggers that never fall at the same time.
4. If you are attempting to resample an existing loop and make it seamless due to the timing inconsistency you may get clicks and pops. However you could take a RNG approach and keep resampling till you get lucky and things fall perfectly in time on the last beat.
5. Seeing the problem when tracking in and thinking this problem is due to midi jitter. Then opting to buy an expensive midi sync box to solve it. The above proves this is not the case and the jitter is inherent to the Digitakt.

Edit: For those who don’t read the full thread this looks to be an issue with the DT/DN/DT2/DN2 (and possibly other products)

[shigginpit]

There is an issue with threshold triggered sampling on the dt2, possibly due to the truncation as a result of the algorithm that determines zero crossing. I don’t know if it’s been acknowledged by elektron, but it’s been identified by several users.

Anyhow, it results in loops which are sampled by way of gated recording (a la arm the sampler and let it catch the transient) being something like a milisecond out of sync.

Is it possible this odd behavior which some have called a bug is impacting your results?

It looks pretty staggered though.

[ripsaw]

No. That would be a problem with either the length or the start point of the sample not the timing consistency.

Lets say the sample was Edit:too fast/slow (170BPM on the DT2 does not exactly match 170BPM in the DAW), but perfectly in time, then the above picture wold be a regular stair step drifting to the left or to the right,

Lets say the sample was started too late, well then everything would be perfectly aligned but offset forward slightly by the exact same amount on each

this is neither, this shows the clock is unstable.

[shigginpit]

As i understand it the grid slicing is subdivisions of the total file length by equal division irrespective of pattern tempo, so a sample which was a MS or less too short (out of sync) might show asynchronous results of some kind, no?

Just to say if the tempo is X and the division is based on X minus whatever, the recording is still of tempo X so you can’t count on it to not be asynchronous in some way, because they are not dividing by the same standard. One is clock and one is division of length.

Although I don’t know that it would look like this. Probably more like the stair step that you described so I guess you’d need a few clock examples to compare and make sure it isn’t just your unit.

Doesn’t scream stability either way though!

[ripsaw]

@shigginpit

I guess you’d need a few clock examples to compare and make sure it isn’t just your unit.

This is exactly why I wrote out instructions above. I encourage everyone that reads this with a DT2 to give it a go.

Edit: creating a file in the DAW of the same sample playing 16ths and loading it into the track with the slice grid, it’s perfect, zooming in on the transient and toggle “<” and ">"there is a very very slight wiggle but it’s on the order of a simple or two, not the back/forth swings there are on the sample recorded on the DT2.

This proves that the grid created by the slice machine with detect transients off is not the problem.

[shigginpit]

It does seem janky. No question. Just trying to make sure we’re seeing the impact of the clock behavior specifically, and it sounds like we are.

If you’re comparing against DAW clock, seems like recording the digitakt metronome audio into the DAW to observe the clock behavior would be an easy test to get more information though.

Although all hardware clocks will be on their own time to some degree, due to the crystal in the timer elements all being different. But that’s more rate than synchronicity, as I understand it.

I’d be looking more at the consistency of the distance between clicks rather than comparing it to the daw clock’s version of the same tempo.

Should show beyond a shadow of a doubt any clock jitter present at the time of the test.

[ripsaw]

The reason I’m doing all this on device is if you start to introduce anything else the excuse becomes jitter on the interface doing the recording/jitter introduced because a computer is involved somewhere. The way I did it here excludes any external interference, it’s being clocked internally and recorded internally.

The entire reason I did this was because I was seeing similar things when recording via overbridge and also when recording directly into an interface, so devised a test anyone could try just with the DT2 alone that did not require a DAW at all.

Remember before the slice update you could not do the zoom in on a waveform with exact time divisions (that as per my previous edit using a file created in a DAW and loaded into the exact same track without altering the slices, the slices are bang on time, so we know they are correct!) before that update you could not easily tell on device, so a lot of issues could be attributed to user error

[shigginpit]

I’m saying record the tempo in audio (metronome) from the device in an unsynced manner and then use actual measurement of distance in between metronome ticks on the recording of the audio wave resulting, using your daw like a visual grid. In that scenario the only jitter present would be due to the DT internal clock.

You’d be looking for inconsistency between the peaks of the ticks as they appear in the audio wave over time. Something on par with the amount of inconsistency you’re showing at present, which should confirm.

You could record the audio into a recorder or straight to the DAW. The results of an unsynced recording of the metronome tick (ie clock) should only represent the DT hardware clock no matter how it’s captured, so there’s not really anything which anyone can say skewed the results.

[ripsaw]

Ticks have the same problem.

Ticks recorded via interface and sliced at the 1 and places one below the other. If there was a static offset, or a clock missmatch you’d not see them wavering back and forth.

[shigginpit]

It looks very consistent to the results above, meaning that the offset is staggered but consistent as it cycles. Not sure what that means, but to me it looks like it repeats every few “frames”.

I’m certain that it was, but everything here was done in a new, clean project with no other settings attached? Just to maintain testing neutrality

[ptomaselli]

Interesting! The original image you posted (which, to be fair, is very zoomed in), doesn’t seem to show any jitter… although each track appears to be off, subsequent hits in each track appear to be consistently off for that track.

If you zoom out, what do you see?

Also, I think it’s worth noting (for others who might read this, since the topic comes up a lot), two devices set to the same tempo will always drift unless they are synced in some way.

I know that isn’t what this thread is about, but techniques of measuring accuracy that assume 170 bpm (for example) is the same everywhere are flawed. So, this seems like a good approach.

wrt syncing, one cool trick I use is to record not via Overbridge, but via regular class compliant USB, directly into Live. This does align tempo settings because while using a USB device as its audio interface, Live derives its timebase from the device’s audio clock (as far as I know).

An interesting alternate test here would be to measure this in this way rather than via resampling. In other words, when recording from a DT into a DAW over class compliant audio, without any additional sync, tempo should be “dead on”. You could then measure the jitter by seeing how accurate the transients are against the DAW grid.

[ripsaw]

It looks like that locally but is not consistent. (in my example above compare the last hit at the bottom a ‘2’ to the other '2’s)

Here is the “1” taken multiple bars apart.

[shigginpit]

but over some measurement, even if it skips ticks, then it implies consistency over time in reference to it’s own tempo. I think it does at least. It’s just not in a musical time signature, right?

Maybe I’m reading too much into it, but it seems like those divisions are all equal length in and of themselves, and then the pattern appears when those divisions are stacked. Above, I mean.

Something is jank. Not contesting that. Could not tell you specifically what but you’re on the right track with collecting metronome samples, if possible.

[ripsaw]

The point is not that on average it’s hitting the right timing. the problem is that it’s not consistently hitting the right timing.

[shigginpit]

Ok, well with that confirmation and since it’s standalone and not connected to midi or receiving any outside information I totally agree something is inconsistent with the internal clock on your unit. At this point it’s isolated, on an island, so until we can compare it against something, we won’t know which direction to head because it’s the difference between a bug report and a warranty claim.

If the impact of the unstable clock is affecting your music making then I would definitely take it up with elektron, if it were me! Not a cheap device by any stretch of the word…

Sorry I can’t do anything other than talk it through with you though, I am stuck with two digitakt 1’s and have not put a priority on upgrading (I’m still relatively happy with DT1 to be honest) but I think that you’re on the right track and producing relatively consistent results for your specific machine so there is hard evidence that something is going on here.

[ripsaw]

correct bare bones.

I describe in the first post the way to set up an experiment that shows you on the device itself the issue.

Please I encourage everyone with a DT2 to actually try the experiment.

[shigginpit]

Unless I read it wrong, your original post says to resample by arming the recorder and then use grid division and I would factor in what I told you, that multiple people have had issues with the consistency of threshold triggered recording when it comes to looping something, even something derived of DT2’s own clock, so just to prevent any misunderstanding about the root cause of the problem, I would not involve internal resampling in tests of clock accuracy. Just for the sake of impartiality.

But do whatever works best for your situation, I’m just stating something that I’ve seen here which might do what you sought to avoid, which is allowing blame to be laid on external factors even if they are still problems internal to the device.

I think that from reading your posts here, I interpret that your goal is to establish that the clock is inconsistent, not simply that DT2 has problems.

[ripsaw]

@shigginpit

threshold triggered recording when it comes to looping something

If you read the OP (that I’ve now added samples to) it’s not using ‘exceed threshold to start’ recording it’s using the start button.

[shigginpit]

I skipped that word! My bad. If you’re recording with length involved, it’s going to be the same truncation as if you used threshold to start the recording though.

I think that the sample recorder when using X bars to create recording length is probably what throws it off the clock.

But since I don’t have a DT2 to test, I’ll leave it to you and the other participants to determine what is accurate!

Best luck!

Digitakt II: bug reports

yeah, unfortunately this means you can’t accurately sample/resample a loop without issues, especially if you want to use the grid machine technical details can be found here

Digitakt II: bug reports

Recorder length is not accurate enough. For example if you choose 16 step R.LEN at 120 bpm default tempo the recorded file is shorter than it should be. If you try to record 16 step loop (trying to make seamless loop without clicking) you’ll fail. The recorded file will play with click if you loop it with play mode FWD.L. You can see how shorter the recodred file is (It should be exactly 2 second length): [Bad length of recorder file] Digitakt 1 does it properly: [Bad length of recorder fi…

etc

[ripsaw]

Again they are talking about length not consistency

My issue is not with the length of the recorded sample it is with the timing consistency

The time between the 1 the 2 the 3 and the 4 is not the same it varies. it averages out to be the right BPM but that’s not the same thing as being perfectly in time

@shigginpit

I think that the sample recorder when using X bars to create recording length is probably what throws it off the clock.

Delaying when a sample starts to be recorded is not the same thing as the beats having different times between them!

What it would look like if it were correct timing :
| _ _ _ | _ _ _ | _ _ _ | _ _ _ | _ _ _ | _ _ _ |
What it would look like if it were delayed recording with correct timing:
_ _ | _ _ _ | _ _ _ | _ _ _ | _ _ _ | _ _ _ | _ _

But that’s not what we are dealing with here. We are dealing with inconsistent timing between pulses:

| _ _ _ | _ _ | _ _ _ _ | _ _ _ _ | _ _ | _ _ _ | < Edit: I should not have to state this (but the world builds a better one each day) this is not to scale.

In fact I bet some people think it’s the length that is causing issue when in fact it is the consistency and before the Slice update you could not see this on the device itself!

@ptomaselli

If you zoom out, what do you see?

It does not matter what you see when you zoom out the delta between pulses is not consistent.