Weird tempo of a sample

Haven’t noticed that… Mines pretty much a looper with only a few samples loaded. I’ve read the manual a bunch of times so I remembered the arrow thing…

1 Like

Ah yes, the gentle art of manual reading.

i just tried selecting between Original Tempo, Trim Len and Loop Len … the arrow does change position by selecting Yes.

Prioritising … very cool!


Maybe its a well known problem, but my recordings are all recorded with a x2 tempo value in Attributes, if I select RLEN = MAX, use QREC = PLEN. Edit : it happens below 80.7 BPM, from 80.6.

Didn’t noticed that before, as I usually don’t use timestretch with my recordings, or used RLEN different from MAX. With RLEN = 64, tempo is correct only if I record 64 steps.

How do you use that? I tried the 3 possibilities, wrong tempo.
With Quick Rec you can check Attributes tempo while recording, and the Arrow goes in front of Original Tempo when you record.
Tempo value is correct while recording, then it is x2.

Does it mean that below 80.7 BPM it’s not possible to record in live conditions something longer than 64 steps you’d like to time stretch with RATE for example ?

Edit : answer in the manual, but I thought tempo guessing was for CF files, not recordings !
Wrong tempo values BTW, (80.7, not 85 BPM), and musically 80 BPM is still too high for certain songs. :sad:

The tempo guessing algorithm analyzes the sample filename for tempo figures,
checking if the initial guess is off by a factor 0.5 or 2.0. The ”normal” BPM range
the Octatrack uses to make its initial BPM guess is 85 BPM-170 BPM. If you have
loops with tempos outside this range, it might be a good idea to put the BPM value
in the filename. Typically, a 70 BPM loop is initially loaded as 140 BPM loop, but if
the number 70 is found anywhere in the filename, the octatrack will use 70 BPM
instead. Similarly, if 280 is found in the filename, the BPM of the sample will be 280.

Yeah, I’ve experienced this with PU’s as you can’t turn timestrecth off for those… I think it has to do with this:

(Which I see you spotted in your edit… :slight_smile:)
Although realistically the value range is slightly different. The opposite is true as well where if you record at too high of a tempo it will half it… I think it works with flex recordings and timestretch disabled…

It’s useful for OT to guess tempo if the sequencer isn’t going, but I think that if your recording sequencer synced loops using qrec and already have the sequencer running it should just set the bpm to the sequencer (which it does if it’s in the range). Seems a “bug” or rather something obvious that wasn’t implemented…

The arrow business I haven’t messed with I just remember it from the manual… I always just make loops synced to sequencer within the bpm range and it works flawlessly and never have to mess with anything… I don’t really use pre-made samples…

1 Like

Yep, I thought tempo guessing was only for external samples, not recordings. An option with recording tempo = sequencer tempo would be nice. I’d use 64 max if I needed time stretch.

The actual range is 80.7 - 161.4 ! @elektron ?


Hey all!

Thanks for all your input! I have tried almost everything mentioned in this thread but no luck… I also tried to create a new project and start over but I hit the same issue with a different track.
Same like previously - one track plays noticeably slower on the OT than exactly the same file does when played on my computer. The track is 174, but when played on OT, its much slower so I can’t timestretch this track properly.
I have exported the project including the files for those who would like to try and repro…
Basically there are 2 static tracks - track 1 and track 5. Both are set to “play free”.
While the track 5 perfectly matches the the OT tempo and locks to the sequencer tempo thanks to the quantization, track 1 doesn’t play nicely at all and even the track is 174bpm, it can’t be matched… At the time of saving the project, the timestretch on T1 might be disabled and pitch might be not 0 - its because I tried few things so don’t forget to change these values…
you can get the set here:

Thanks for any input!

Are there any fluctuations in BPM in the track. If somehow the information was retained that may be your problem. even the smallest fluctuation of 0.1 bpm can affect an export and at such a very high bpm this seems likely. Warping may not have helped and you may have to do it manually with markers in Ableton. I dont think its a problem with the OT but in Ableton itself.

Its not wraped - its just a converted mp3. If I play the same file on my cdj, its stable. If I try to wrap this wav (the one used on T1) in Ableton starting at the very same point as the start marker as 174bpm straight, its also ok and I don’t need to do any adjustments nor add any additional warp point.
What really mystifies me is that the track definitely sounds slower and little bit pitched down when I listen to it on the OT with TSTR off when compared to the same wav file listened on the computer… I have absolutely no explanation for this to be happening…

Try cutting the track up into smaller parts then exporting. See it that works. There may be some that stay at 174bpm and others that dont. The high bpm may have small innacuracies that the OTs software algorithm has detected.

Yeah that’s a good idea… I haven’t tried to split the file yet…

But still - if I told OT that the sample is 174 and the project tempo is 174, why would it timestretch? Why would the same sample sound differently on OT and on the computer even the timestretch is off? :thinking:

try using a different program to convert the mp3.

audacity may be of use, try doing a 16bit and a 24bit version.

1 Like

I suggest verifying the sample rate using a computer one way or another…
On a Mac in finder you can click “get info” I think it is and a window will pop up that says…
It’s the only thing that really would make sense…

The OT can tell you too in the place where you load samples to the slots…
There’s a little face that will smile if it’s right and have a straight line mouth if it’s not…

1 Like

Sounds like a 48khz file. Played slower.

1 Like

yes - although the Digitakt and AR will handle 48khz natively, OT only goes to 44.1khz

whereas Nigel’s guitar amplifier goes to 11.


Just checked - OT sees both files as 44.1k, 24b, 2ch. Even the source files are 44.1k.
Did anyone hit the same issue with the project I uploaded?

This is getting more and more weird… I did another round of experiments and created a new empty project.
Into this project, I loaded only one file and assigned this file to the static machines on T1 and T5. I changed no setting of these tracks but only set them to play free so I can trigger them manually… Guess what - the same file sounds different on T1 and T5… On T1 I hear a slight timestretch and the sample is pitched differently. On T5, it plays as expected. If I load the same sample to T2, it also plays nicely and the pitch and the overall sound is the same as on T5 - its only and always T1 having this issue…
Even if I load the project I uploaded here earlier and assign the same sample as in T1 to T2, it works fine…
I am not getting it… - Am I hitting some bug? Is there any setting in the OT which I could possibly changed, causing that the T1 sounds different even on a clean project?

Seems I am an idiot ladies and gentleman! The correct answer is…tadaaaaa…p-lock!
Thanks for all your input its really appreciated and sorry for taking your time with such an user error… Lesson learned :slight_smile:


For a newbie getting used to the OT. Can you explain how p-lock can affect imported sample rate for future reference. Cheers!