The practical implication is that the decimal tempos are not exactly what gets displayed. For example: 89.7 is not 89.7, but 89.75. So you’ll need to be extra careful when you use them (and don’t trust the display).
2 Likes
Or just trust your ears
2 Likes
This won’t help you, because you cannot dial in a different BPM decimal value that matches the required one (when it falls in between the allowed 24 distinct decimal values).
interesting…
Id always assumed sequencers would time the gap between pulses in samples, and then use that to derive the tempo.
Several, I should report them on the first post.
I’d like to make some tests to confirm. Anyone can help!
IMHO, mainly problems with looped samples, long samples that can drift progressively, with slices that can clic…
A 101 bpm theoretically won’t be looped correctly at 50.5(416) bpm.
Slices may clic.
You have to be carefull with samples you export from a DAW.
Sometimes I calculate sample length in samples. If the tempo is wrong, length is wrong.
I guess it’s valid for all Elektrons, eventually any gear with midi clock?
no, see my comment above…
24ppqn does not mean you have to count pulses over a minute and divide,
that is just one way you might calculate the tempo…
in practice even the octatrack does not do this… if it did then with an external clock you would have to wait a minute before it tell you the BPM, which is not what happens, you usually get the BPM fairly accurate within a couple of seconds.
so what it is doing (and Id bet almost all sequencers do) is time the gap between pulses.
it will then likely use a rolling average of that time, to account for the vagaries that are introduced whenever IO gets involved.
(so the tempo resolution is not limited by 24ppqn but rather than accuracy of your clocks, and also IO jitter)
4 Likes
One reason might be that they are processing DSP in blocks of, say, 32 samples. Maybe they always loop a pattern (and thus start/stop recording) at the start of a new block of samples? 32 samples at 44100Hz is only 0.7ms, so it would not really be noticeable.
Well, other gear may behave differently and internally you can always use a higher resolution. The 24 ppqn are just fixed when communicating to the outer world via standard din midi.
I guess it does both. Timing the gaps + counting with a sliding window. The most problematic point here is that you want your tempo rock solid, but also quickly adapting (when slaved). So clamping to a set of distinct possible values make sense to prevent jitter influencing your tempo too much (since the original MIDI speed is sooooo slow that transmitting a single message takes already “ages”).
1 Like
Might be slightly off Subject…it I want to sample vinyl loops live. Say, 2 Bars to keep it simple.
What I would love to do is have my decks play with all record 100 percent tight loop. At the Moment I’m doing manually and the loops glitch. I don’t want a glitch right now.
I can set the record bpm manually on the deck. I want to live loop off Records. Set by a trig a so I don’t overdub. How do I record the loop and if that’s successful can I shift to loop start point. Please say this is possible.
Thanks
Hmm, yes I guess under conditions where sequencer is not used to restart the loop this could be a problem, most of the time I do use the sequencer but handy to remember this for the times that I don’t.
Edit: What about if the sample is trimmed precisely to the target bpm in AED, I wonder if the looping routine takes this into account? i.e is the tempo in AED matched to sequencer tempo or actual tempo?
1 Like
For me it is not acceptable that in many cases you can’t use half or double tempo.
You have to change scale instead, otherwise you can have noticeable clics with slices for instance. I whish they added all 1/24 divisions.
Odd decimals can’t be multiplied by 2.
0.1(25)x2 = 0.25, closest is 0.2083
Natural odd numbers can’t be divided by 2
101 /2 = 50.5, closest is 50.5416
2 Likes
So it’s not possible to use OT Rtim at 440 hz ?
This might indicate that AED doesn’t correspond with OT sequencer tempo, but actual BPM - would you concur?
That’s sure.
Maybe a bpm with 1/24 values.
1 Like
Ah yes!
This is an interesting discussion and I feel like we should keep in mind that Midi clock is relative time keeping based on the internal clock, as calculated from the frequency coming into the voltage mains. It seems like there could be some confusion on that. Midi clock counts beats and looks for start, follow and stop messages every 24PPQN. This is all very different than real world timing like SMPTE.
Point being, you’re going to be occasionally disappointed if you’re importing loops with fractional tempos and are expecting them to loop seamlessly on any other device. The Midi clock sync spec simply isn’t written to accommodate this as it relies on relative timing, not absolute. This isn’t an Elektron problem, but some laptops and drum machines may be more on “island time” than others. 
In theory, you should have tighter synchronization if you can slave to MTC.
1 Like
Probably! For me, concerning OT, the important thing is to export samples with the closest tempo to the available values mentioned in the op (and natural numbers). What is displayed is not precise at all. The worse being 0.9(5833).
If you use timestretch, more values available (1/24 multiples for decimals).
1 Like
Increased precision would be useful but still wouldn’t solve the problem of relative time keeping though. You’re asking for increased precision using a specification that has you wanting for more accuracy. I’m suggesting that your complaint is more with the accuracy, which is not something easily solved given the specification. 
We could drive separately in 2 autos, both traveling at 100kph indicated. We would each arrive at our destination at slightly different times. Now I could choose to follow you closely but I would have to periodically brake and accelerate to keep a steady distance to you. It’s essentially the same scenario.
1 Like
but i thought the point of the OT was that if you pop a track down at 101.1bpm or whatever, the OT will stretch or shrink the other loops to fit the length of the pattern or the tempo.
if one is getting very granular and making sure their loops are down to the exact length they need to be to match up with 101.565656omfglmao56565 bpm, i can see why this might be an issue.
i’m just wondering from a non power-user perspective what it all means. I trust my ears, and i enjoy this thread. but i’m wondering about the practical implications for non power-users when they make their loops.
1 Like
I would say, just stay away from decimals. Natural BPM numbers are fine. Everything in between two natural numbers gets “messy”.
1 Like