Midi Clock Tempo Stability

Elektron Gear Octatrack
#1

Hi all
I’ve been working on a project at the tempo of 174bpm and have noticed on my neighbouring midi-synced machine (Octatrack) the tempo drifts up and down from 173.9 to 174.1 and never stays put.

This creates some stuttery artifacts on some timestretched samples which are undesirable.

I figured it may have something to do with instability at higher bpm’s so I halved it to 87 and voila! Perfect sync, no drift at all.

For all those suffering with some midi tempo instability - halving the tempo (and setting x2 pattern length multiplier) may work for you, give it a shot.

1 Like
Ocatrack tempo annoying decimal when clock syncing
#2

Nice workaround, but limited if you are trying to sync other stuff that doesn’t have tempo multiplliers, like, I don’t know, lots of stuff, other Elektron gear?

I get regularly clock slippages circa 128bpm…

#3

wondering if anyone solved this?
my Digitakt is getting clock from an OTMk1 - usally around 125 - 130 and it does the same thing. randomly cycles around, for example, 130.1 , 130, 129.9

honestly i’m not really noticing it - but its concerning.

#4

Digitakts always show small tempo “drifts” on the BPM counter when slaved, it’s normal - I wouldn’t worry about it unless you can actually hear it going out of sync

2 Likes
#5

I’ve seen those small tempo fluctuations on quite a few midi slaved synths, never actually heard the tempo warble around so it never became a real problem.

2 Likes
#6

:hugs: okey dokes - thanks - good to know it’s not just me at least.
i think the key is to stop looking at it … lol

2 Likes
#7

Hi there

My Octatrack is synced to another clock source, where the tempo is 120. Annoyingly, it always detects it off by .5, so I get a 120.5 bpm reading on the Octatrack instead of 120.

I read on a previous thread that the LEVEL knob can control the tempo whole numbers - True.

I also read that the A knob controls the decimals - Not true here.

Am I missing something?

Also, if anyone can chime in as to why the Octatrack clock sync is not 100% accurate?

Thanks for your time.

#8

Use the arrow buttons for decimal BPM adjustment.
If you want octatrack to be dead on 120bpm, have octatrack be the master.

Variances in BPM detection are due to variances in clock calibration. Ableton, Elektron, Korg, you name it, they all count time slightly differently.
If you can hear that your machines are out of time, then you have a problem.
If you are looking at a screen and worrying about half a Beat per minute, I would suggest life is pretty good, and you aint got no troubles.

Pro tip- a slightly drifting clock is actually a good thing, it will help your music appear less robotic.

5 Likes
#9

Thanks. I definitely can’t hear any problems, and the metronome of the OT and my source are fairly in sync (enough).

The thing is it becomes apparent when sampling. Say I sample two perfect measures, with the source material at 120bpm, the OT for some reason truncates when the pattern resets when I play the recorded sample on the OT exclusively.

That was actually the reason for my post. I put it down to this decimal variance in the tempo, but maybe it’s something else.

The material definitely gets cut off when I play the recorded sample on the OT.

#10

Audio editor/attributes, check bpm. If not 120, change it so it is.
Also, sample for slightly longer than you think you need to. You can always crop samples anyway.

1 Like
#11

‘sample for slightly longer than you think you need to’.
This exactly. I was just replying with that as being the solution.

And after testing, this is the solution. The tempo variances are so small they are no issue (as expected). The problem was being caused by quantized (pre-determined) record length.

However, I still think the OT should have the ability to avoid truncating samples when using exact quantize record method (for your actual intended length of sample). This is simply not an option if you want clean, smooth loops of sampled material.

#12

Can’t you use OT master?

#13

No, my DAW is the master. I have a hybrid workflow

1 Like
#14

Another approach. Export your DAW sounds as a wav. Drag and drop the wav files to your OT flashcard.
Thats how I made pad, perc and fx sample chains a few years ago. I dont really use a DAW anymore.

#15

Sorry to revive the dead, but I have been experiencing this recently.
I route midi Takt source > Tone Thru > OT and when running a synced thru machine and recording the takt and the tone to a buffer in the OT I get noticeable drift. I thought leaving vinyl DJing for hardware with clocking was meant to solve clangers, but its quite bad when you lose midi sync!
I find beats can get quite far out of sync, so a solution would be much appreciated. Maybe a buffered midi box like the midihub?

#16

What do you mean by “noticeable drift”?

1 Like
#18

Like somewhere in the region of in sync up to a beat off between the sampled buffer and the what comes in through the thru machines from the takt and tone.
Maybe it was user error with the OT and I did something wrong (I hope this is the case), but I couldn’t find any evidence and on a fresh stop-start-record everything was in sync again.

#19

Never had any major sync problems in my (all hardware) setup, lots of gear synced up OT as master or slave, I use thru boxes rather than daisy chaining, and any piece of gear that can’t sync properly is quickly removed from my setup - ain’t nobody got time for that.

Regarding the display readout, some gear averages the displayed tempo, some gear does not, I suspect that the polling interval to read the incoming clock varies on different devices too, all of these things can have an impact on the displayed tempo, it does not necessarily mean that the tempo is fluctuating though.

Main thing to ensure if slaving OT to anything is that you enable both transport and clock in, and on the master device you ensure it is sending both transport and clock. If this does not solve it, try a different midi cable.

Hope it helps.

#20

When you say “noticeable drift” I guess you are not syncing the playback of the recording but letting it - once started - freely loop, aren’t you?

The problem is that the recorded length is due to some possible midi jitters not exactly the length you think it is (there are more or less sample values in it). When this recording is freely looping over and over again these “more or less” samples builds up into a noticable drift.

IMHO sampling some steps and then let it freely (unsynced) loop can only work stable on a machine which is master, but never ever on a midi slave. If it works it is pure luck that you hit the exact length (matching the average) during sampling.

Workaround for a slave machine: don’t loop, but retrigger the playback so it stays in sync.

1 Like