Cubase Process Tempo - is this buggy or what am I doing wrong?

[lfm]

I imported some audio and placed marker track, timebase time, so these markers does not move with tempochanges.

Entered length or end to a marker what is should be in bars - and it just ends up crap tempo.
I experimented for hours and still not something I can use.

I get a node about 1/16 before where I expect, and calculated tempo is not close.

Tried various settings whether main ruler is bar+beats or not etc. Tried visual as bars linear or not as well.

Any ideas?

Thanks.

[jancivil]

never mind[/E Litella]

I like Warp Time.

[lfm]

Thank you, but then I did not describe very good.
Audio should be what it was - and just get a grid and tempo to do midi stuff later on this.

Calculating manually from time position and how many bars - tempo should be different than Process Tempo do for me.

Time position 01:01.734=61.734 second.
32 bars
4/4 time signature means 128 beats.
128*60/61.734=124.404 bpm manual calculation.

Main ruler timebase bars+beats.
Dialog calculate to 124.309 and places a tempo node at 33.0.3.211(from project start so length 1 bar less).
This is time position for new right location.

Changing main ruler timebase to time and primary time is time and secondary bars+beats.
Dialog calculate to 125.308 and places a tempo node at 33.1.2.211 but marker is at 33.1.4.183(from project start so length 1 bar less).

Changing display between bars+beats linear or time linear does not change values at all.

But chosen timebase on main ruler changes values.

But none of them correspond to my manual calculation. I expected position of marker would be at 33.1.1.0 as tempo was recalculated and still at 01:01.734 in time.

I later have a break and yet another tempo and stuff, and though this would be a cool way to get exact tempo in an easy way, part by part - but no go.

[lfm]

Jancivil - you gave the clue I needed, thank you.

I used Time Warp and setting warp grid instead - and could just drag grid to line up to any time position.
Seconary time chosen, I can also just enter a value if visuals are not good enough.

So locators to range, change to time warp on toolbar, and again to select to choose from menu warp grid.
In the middle of project windows somewhere cursor shows a bar to drag to line up - exit time warp - done.

I get tempo 124.394 setting marker at 33.1.1.0 which is different than manual calculation 124.405(I truncated digits above, not rounded) but will check further how it sounds. I see that changing time span to 61.740 instead, tempo become 124.393 so yet another millisecond and it become same as Cubase do. Rounding error of 1ms maybe how position is presented to you. Calculating by sample might be more accurate what time position is.

At least I seem to be on the tool that is made for this and seems really cool indeed.

[jancivil]

Yeah, I do this all the time. Time Warp with everything in Linear Timebase, to determine where bars are when it's unknown {"to get a grid and tempo to do midi stuff later on"}. When I write, it's always unknown until I do, I don't try to imagine the tempo and conform to something I set, I do music and make the timeline conform to what I've done. (Unless it's a cover and tempo _is_ known.)


I was going to test Process Tempo; tbh I never used it except to try and expand the mysterious shrunken MIDI parts.

I do use Insert Bars in there all the time but I have yet to feature a need for the former.


I do have to stretch audio occasionally very precisely and to do calculations I set Time Stretch and the timeline to samples, if only because it's objective and not up to my idea of the timeline. And it's just easier. I wouldn't worry about other numbers than tempo indication in your case scenario.

[lfm]

Thanks again. I'll have a look at using samples too, it's 48 samples every millisecond so more accurate.
Time Warp will also be perfect to adjust to scenes in video - and adapt to feel of each scene.

I'm not always in favour of how Steinberg call things - I really thought process tempo would do what I wanted.
Especially looking at fields in dialog. I'll search their bug report forum and see what people say.

Looking at process bars I thought it could work too at first glance. Probably good when needing to change time signature in part.

[jancivil]

TBH I'm uncertain as to the real world use cases, except it was at the end of the day the final resort for my stretch the shrunken bars to where I could even see them. I don't have any idea how accurate it was, because I had a very convoluted timeline and all bets were off, it was extremely coarse.

Working with picture, you'd notice the length of a cue and go into process tempo in terms of time per se and with the locators it works, the timeline now gives you that exact time within the locators and you write the cue in that span of time. I don't think of bars and beats or setting tempo in that way, as I suggested I do that as a quantification of what I've already done; so except for that particular use case I never thought twice about it.
Googling this out of curiosity I found someone at steinberg.net that wanted one bar turned into five bars and just didn't get how the tempo was now five times slower.


I have occasionally noticed odd behavior but getting into it isn't going to be so useful.

[lfm]

I found out today what was wrong with Process Tempo - they did create a scaling that was reverse from what should be used to calculate.

So I had this range after importing a to a project set as 100 bpm.
The range showed as approx 25 bars long, and I wanted it to be 32 bars even.
So Cubase multiply by 0.8039 factor instead of dividing it and setting new tempo to 80.39 in this example.
If you reverse that it become 124.395 bpm which also my calculator says.

Steinberg obviously make features nobody uses...weird....

[jancivil]

That isn't what's occurred here.

I just did a very clear test. Start w. 4 bars at 100 {range = bar 1 thru bar 5}; now establish "new range" as 5 bars {thru bar 6}. Now the tempo is 80.

Yours (simplified): 25 bars at 100 to 32 bars, new tempo is 78.125.

25 ÷ 32 x 100 = 78.125.

[lfm]

Thank you for making the test.
You press more bars into the same time space - that means it should increase tempo, to get those extra beats in there.

You increased from 4 to 5 bars - and tempo lowered - it does not make sense to me.

So final calculation of 32 bar 4/4 into 61.739s mean 124.395 bpm(128*60/61.739)

It shows a scale factor in dialog - divide by that instead of multiply as Steinberg do now - and it becomes as manual calculation tells.

Do 1/0.8039=1.2439 and other calculations by scale factor - and all fits well.

And my example of 25 bars mentioned was roughly, if it was 25.2.3.143 or something.

[jancivil]

No. It takes more time to do 5 bars than 4, hence the tempo is slower.

[jancivil]

100 beats per minute;
in 4 bars you have 16 beats. Now we're asking that this passage be 20 beats. This is 5:4 in terms of the time used;
the logical calculation to get BPM is to invert this. 4/5ths of 100 = 80.

<In terms of the time used> is the crucial clause there. It should be clear 'takes more time' = 'slower clock' just in the basic sense.

[lfm]

100 beats per minute;
in 4 bars you have 16 beats. Now we're asking that this passage be 20 beats.

This is 5:4 in terms of the time used;

Thanks again.
Not as I see it, not at all.

You request the now 4 bars time span to be 5 bars, which is 20 beats - yes.
So you increase New Range Length field to 5 bars.
But within the locators set - which is the time.

Midi normally follow tempo, so it makes no sense to see locators as a midi position.
One bar in midi is one bar whatever other tempo you get.
So we talk about a position in a audio event(part,clip whatever) - time linear.

Now do Process and see how values in New Range change - instead you want actual span Start to End to change to the requested in New Range.

What is happening now - makes no sense to me - not in any context.

You set a requested New Range - and expect to get that.

the logical calculation to get BPM is to invert this. 4/5ths of 100 = 80.

<In terms of the time used> is the crucial clause there. It should be clear 'takes more time' = 'slower clock' just in the basic sense.

It does not make sense to me - that to request New Range to 5 bars should adjust tempo node to take longer to get to locators.

This would suggest you see tempo as fixed, and time to be warped.
Tempo is what dialog change/adjust - hense the name Process Tempo.

There are other features in Cubase to insert time as expressed as bars. That's completely different in that you want more audio in there.

Tempo changes are musical grid changes, not time changes.
Process Tempo dialog is to process tempo to fit locator positions to a range you select.
You try to make grid fit to a certain position by adjusting tempo - and tell New Range is to be so, so bars.

And dialog do the opposite now - to my understanding.


EDIT: It seems dialog is doing what is intended. Confusion on terms used for me.

What dialog is supposed to do is to alter playback duration range for midi stuff by altering tempo, basically. No range of bars is changed for a certain clip - just how fast it plays back.