Question regarding tempo track and audio files obtained by direct recording

I have activated a tempo track and a signature track, and I am recording various instruments amongst them electric guitars, synths and midi flow from an external source.
I proceed by group of bars (my recording sessions) using recording loops.
In some of these sessions, the tempo track changes several times its value.
What does Cubase for the corresponding files regarding tempo changes: does cubase fragment the files respecting each tempo change, so for each loop I get several files by recorded track ?
When I open the pool, things are not very clear inside it ? What whould be the expected result concerning these files ?

Wut ? Your files are recorded as you play in real-time, the tempo change is already printed in the recording since you adapt your playing to follow a metronome.

Cubase has no way to detect this, a file can only have one tempo information, and currently when there are tempo changes from the Tempo Track, Cubase sets it as the average tempo, which is totally impractical imo, it should at least set the tempo from the start of the recording, but recording with tempo change is already impractical all alone, regardless of the tempo set in the Pool.
Let’s say you want to import a file from an old project and you don’t remember if it was recorded with tempo changes, then you’ll notice that quite fast and have to adjust the tempo track accordingly.

Thanks for this answer which confirms the great limitation of the tempo management in Cubase 12.
If my tracks all receive an average tempo, I agree it’s the worst solution which has been chosen.
So I guess that I am loosing all the features based on musical mode and/or tempo adaptation.
It could explain some strange results I get when trying part of them.

Having only one tempo stored in each file is a serious limitation.
Is it too difficult for Cubase to start a new file each time the tempo changes during a recording ? Or to store each tempo and its position in the file ?

I can’t partition my recording/playing based on an idea of tempo value unicity,.
From my playing experience, it’s important to have the real experience of the tempo change in one recording. Many historical success could not have been built with Cubase considering this limitation.

And what about signature changes, sync or not with tempo changes ?

I think you are asking for the impossible, it doesn’t work out the way you imagine.
There’s no software on the market that is able to embed a “snapshot” of tempo and time signature changes in audio files.
Musical Mode is intended for use with files that have one fixed tempo and one fixed time signature, and this is seamless between all major DAW.

You can still split your main Event into multiple Events and render in place so you have separate files with separate tempo.

Many historical success were built with kilometers of magnetic tape, chunks were cut with scissors and glued together with adhesive, there were no computers and digital audio files, and yet people managed to get out of it, how’s that possible ?

Yes, that’s life

Yes, I have made all my life in computing from the early days to more recent cloud and mobiles, again that’s life.
At one time this industry took the bad path looking to its recent achievements :upside_down_face:

Hi @csurieux !

I record in a fashion similar to what I think you may be describing, including varying tempos throughout a project (“in one recording” as you write), and it turns out OK without significant problems I can identify.

It is not clear to me whether you are having a problem editing/mixing due to varying tempos, or simply observing the pool tempo is not as helpful as it might be regarding the varying tempos.

If you are having a problem working with a project that has multiple tempos, please post back with some more specific details/examples and I’m pretty sure we can help/offer some solutions! :slight_smile:

1 Like

Hi, thank you.
I was just asking for precisions on how Cubase was handling this, @Louis_R brought the answer.
And I thought, this could certainly be optimised.

Because today when I open Pool I can see many files, but none with any of the tempo I used.
As this

An when I tried adapting some sections of my tempo track, things start rocking not the way I have been expecting.
Later I started to use Free Warp to adapt some lanes of my group recording and it ended by the unfamous warning “real time algorithm has been deactivated…” .
From this point the project was lost and I had to restart on a backup and re-record my last takes, using a different cutting.

Yes, this can be tricky (IMO)! Post back with any specific issues if you like of course.

This is not the expected behavior :frowning: Similarly if you post some more details, someone here will likely be able to help you out a bit.


I have already posted concerning these problems.
The “real time algorithm has been deactivated” warning seems to be a mystery in these forums.
And concerning adapting tempo track for files recorded with several tempo change, it is the total desert. All the threads are about mono tempo recording and all the youtube video also.

I came to the conclusion that the problem is laying in the multi-tempo sound files and that it is a major flawness in Cubase (and in any other Daws if I follow @Louis_R ).

You probably have two markers too close to each other at some point, and they may be hidden after resizing the Events. This message doesn’t show up for no reason :smiley:

In this case I removed all the markers but the non removable ones at beg+ end.
taking care to remove the hidden ones (the worst ones) in hidden parts of the file, the warning is still here. I am not the only one.

Cubase already “definitions” for tempo information. What is missing is a function to split audio events at tempo events and transfer the value from the tempo event to the audio’s tempo definition. It would probably have to create new files. I think many of the necessary ingredients are already present in Cubase. The tempo value transfer is missing. This has to be done manually for each event at the moment.


I agree, but how to manually split the file ???
Some steps are missing in Cubase concerning tempo track and recording.

I don’t understand why you absolutely want to do this. I mean, since you are already recording live audio signals where the tempo and time signature change over time, this is already very advanced in terms of musical writing compared to the average “bedroom producer”, who’s instead most likely stuck to 4/4 - 120 bpm.

As suggested in one of @alexis posts above, it would be very interesting to know in which way how including a “tempo/signature map” in WAV files would improve your workflow / what use would you make of such a feature, if you don’t mind sharing that with us. :slightly_smiling_face:

Splitting an audio event at tempo track events can be done this way:

  1. in the Preferences make sure to have deactivated the option to select the track automatically by selecting an event
  2. select the audio events to be split
  3. select the tempo track
  4. use function “go to next event” (default key “n”), then use split function which is by default bound to Alt + x

If you like you can then select all the individual audio events and bounce them to new files as @Louis_R suggested above.

For the tempo information I tried to use “Set Definition from Tempo…” but that doesn’t work. So you’d have to go to the pool and enter the tempo for each of the newly created files.

Thanks @Johnny_Moneto & @Louis_R for your last infos … but it would be really difficult to fragment this special song which is very long and base on an alternance of several same tempo values. I know how to cut events and how to render in place but with 12 tracks what a time consumming task and pain.
And doing so I am not sure to keep same potential of modifications, especially on frontier of events with free ‘buggy’ warp.
I would prefer that Cubase be able to assign several tempo to a same file rather than assigning a badly cut rib when it select the average tempo for each file, for me it is a conception error without any justification.

I didn’t post the steps in order to inspire you to copy them. I find it also tedious. Instead, in case this gets forwarded to the devs, I wanted to show that the ingredients are already within Cubase. What is missing is to combine them to a function. Since Macro and PLE are not powerful enough to deliver that in this case, it would actually be a feature request.

Maybe you like to add the “feature request” tag to your post title?

BTW - for the manual way of doing things: the splitting and bouncing take the same amount of user interaction time be it for one or for many audio events. You just select several of them at the beginning. The most hidious part is the manual entering of tempo information inside the Pool.

To have changing tempo information within one clip (please note that Cubase tries to avoid touching the actual audio file and merely uses references called clips, events, and regions) seems interesting but I wonder what would happen if such a clip gets inserted into a project with steady tempo and then all possible audio edits are being perfomed on it.

It would be better to create a clean new thread, the discution here has gone through many different paths, if you do it I will support. :wink:

On another side I am not totally convinced now that truncating in several physical files just on the tempo change could be a great solution because on certain slow tempo electric guitar parts when I play arpegigos with great distortion and delay on the amp, then when I follow this sequence by a sequence of faster bars arpeggios with palm muting and huge tempo change, the sound of the last slow apeggios continues on the beginning of the second sequence. Cutting the audio file on the tempo change would cut this effect and prohibit any further fix using free warp (I don’t know how to use Free warp on the barrier of two physical audio files limit ? Could it be done ?)
The thing being complicated by the loop recording and the several lanes generated by the loop + the several tracks recorded in parallel inside a same group track to be able to apply same modifications later to all tracks and their lanes…
May be it would be better that Cubase memorizes several tempo values with their position inside the audio file it generates, rather than simply one tempo value and this strange decision of averaging when it encounters a tempo change duting the recording.

My final thinking is that when you push Cubase 12 in its limits using several of its advanced features -tempo track/signature track/audio files/free warp/loop recording with lanes/tracks grouping inside a group track- in this situation Cubase does not behave correctly and you can’t keep control of our modifications.

My point on this was that it would probably create a whole new mess once the audio file would be taken out of its context in which it was created. There would be a lot of “what if the user will do that…” cases to be considered for such a feature.

I will not put it up as a feature request as I don’t need such a feature at all. I’d rather like to see the devs spending their time on other things.

I totally agree, imho there’s no need for a feature like this, and actually that’s the very first time I read someone speaking about that here on the forum :face_with_raised_eyebrow:

If not being able to store multiple tempos in a single file was such a big deal, I imagine more people would effectively complain and bring up this topic, but it doesn’t seem to be the case.

I’m not saying this isn’t a good idea, but I really can’t see what would be the use cases.
You were asked in which way that would improve your workflow, or what would be the exact associated functionalities you would expect from it, but you didn’t give us a precise answer, the only clear thing is that you want the file to store the tempo track, but what for ? The question still remains :thinking:

That’s the exact reason why people record different sequences separately. :sweat_smile:
If you record everything in one go, you’ll have no control over the different parts… and this is a general thing, no feature will ever “fix” that.