I made a mistake in the opening post, the loop was 4 bars, not 2. With a 2-bar loop, the sample editor gives tempo 127.70 BPM, and the same results come regardless of whether the silence was recorded To Clip from e.g. the launch mode, or To Arrangement. Recording a 4-bar loop produces 127.85 BPM in the sample editor.
Where the numbers come from can be calculated. In the beginning of the recorded WAV, there's a 384 sample "pre-roll", which is probably good to have for reducing clicks or something.
Recording a 4-bar loop Project tempo 128.00 BPM. Results in the sample editor:
START : 384 (samples)
END : 331133 (samples)
Length = end - start = 330749 (samples)
BPM : 127.85
Recording a 2-bar loop Project tempo 128.00 BPM. Results in the sample editor:
START : 384 (samples)
END : 165758 (samples)
Length = end - start = 165374 (samples)
BPM : 127.70
Where do the BPM figures come from? From this formula:
Tempo = LengthBeats * 60 / (LengthSamples / SamplingRate)What's happening?
- First of all, they're CALCULATING the tempo instead of getting it from the project. I am recording things in 128.00 BPM so why not believe that?
- Second, they're using the END value directly as LengthSamples, instead of END - START.
For the 4-bar example, we get:LengthBeats = 16
LengthSamples = 331133
SamplingRate = 44100
So they get:
tempo = 16 * 60 * 44100 / 331133 = 127.85195073when they should be getting
real calculated tempo = 16 * 60 * 44100 / (331133 - 384) = 128.000387For the 2-bar example, we get:LengthBeats = 8
LengthSamples = 165758
SamplingRate = 44100
So they get:
tempo = 8 * 60 * 44100 / 165758 = 127.70424354when they should be getting
real calculated tempo = 8 * 60 * 44100 / (165758 - 384) = 128.000774I don't like this behavior. Maybe there's someone out there who loves it and finds it useful.