To reproduce:
Expected behavior: recorded audio should have a valid tempo - the tempo it was recorded at. Note that non-cycle recording does have a tempo, and it is correct. The problem is only with Cycle recording.
As further discussed in the old thread:
Mac OS 10.14.6
Cubase Pro 11.0.41
Hi,
The Tempo is not overtaken from the project. There is an algorithm to find the tempo. If you were recording just a noise, of course, the tempo is unknown.
The reason why the Tempo is not overtaken from the project is, lots of users are not recording to the grid, if they are recording just the audio material. Therefore the Project tempo is completely irrelevant for these users.
Hey Martin:
I’ve heard this explanation before, and it is really a non-answer:
The tempo of recorded clips is correct when not using Cycle, but broken only when recording in Cycle mode. Surely you’re not saying that somehow one no longer cares about the Grid when recording in Cycle mode? Yet somehow we do when not cycling???
I understand that an algorithm is doing this, and maybe you, personally, don’t see its abject failure as a problem, but clearly the algorithm doesn’t work in this most basic use case: cycle recording multiple takes of a live performance. It doesn’t even provide an answer at all, just “???”. Surely, you’re not saying that this is the expected and designed behavior?
It would be a colossal mistake to try to explain the bug as a feature, saying, “See, the algorithm can’t figure out the tempo, and thus throws up it’s hands, just like it was designed to. Therefore, the algorithm - and Cycle recording - are working just fine.” aka, “It’s not a bug, it’s a feature!” Thanks, engineers.
In this case, the magic doesn’t work. At all. It should at least have a way of being turned off (and arguably not the default).
There are plenty of other, on-demand operations in the Sample Editor for working with beats, Hitpoints, Slices, etc., That would seem a much better place for the automatic Tempo detection that this algorithm does, rather than where it is in the flow now.
In any case, clearly this algorithm, as currently implemented, should not be the default, with no way to disable it, as it breaks this most basic and very common - and very well documented in the Operation Manual - use case.
cheers,
– jdm
Hi,
OK, this is an interesting information, I didn’t pay attention to enough before. And you are right. I have just tried it and I can reproduce it the very same way.
Interesting fact is, the lanes are actually only one file. You just get the “window” to the specific part of the file by the lanes.
The Cycle could be also based on the Time grid. So the fact, Cubase doesn’t use the Project’s tempo is still valid.
It’s never about my personal opinion.
I’m going to report this as a bug.
thanks, and i want to apologize for being crabby and snarky; there’s no excuse for that.
cheers,
–jdm
For me when I cycle record it usually sets the Tempo value in the Pool - but the value is always (???) incorrect.
When I just record without cycling the Tempo value is correct.
My theory is that when cycle recording the actual length of the recorded audio isn’t an exact multiple of the Loop Length which messes up the Tempo calculation. So doing 4 takes yields an Audio File that is
(4 x LoopLength) + a little bit more
Hi @raino,
This is exactly my observation.
Why do you think so, please?
The lanes are actually just visual representation of one audio file. If you open the audio file in Pool (or even in Finder or Windows File Browser), you can see, it’s just one long file X-times the length of the loop. So Cubase just offers the “window” view on the file.
You can also easily expand the boundaries of the Audio event and get the whole file.
Yeah, I do this on occasion. Especially when recording where the loop is acting more like a vamp to solo over rather than a series of distinct takes like for a vocal chorus. When I do this, I drag the lower left of the Audio Event on the first Lane as far as it will go to reveal the entire Audio File. However I’ve noticed when doing this that the end of the Audio File/Event doesn’t line up with a bar line which it would do if it were an integer multiple of the Loop length.
Because you’re cycle-recording to record multiple takes, and you’d stop recording shortly after the last take, i.e., the cycle-recording has already started on the next take, which you don’t care about because you’re done.
So if you record, say, 4 passes (cycles), and then stop after it’s started the next cycle (which of course happens immediately, jumping from the Right Locator to the Left), you’ll have audio 4x the distance between locators, plus the little bit from the last.
This would be true whether you’re using bars & beats or using time.
–jdm
If you Lock the Punch Points to the Loop it will record as one long multi-take Audio File (like above) because the Loop Recording never goes past the Punch Out Point. If once the Loop was set you unlocked the Punch Points and then moved the Right Locator 1 Tick to the right & just after the Punch Out Point. I bet when recorded like that the Tempo would end up being correctly set. Of course that would also mean that each Take would have its own unique Audio File. That would be useful if you wanted to do stuff like Pitch Shift each Take by a different amount.
Can’t give it a try at the moment…