Changing the Tempo doesn't use the Snap Point and makes Events lose their position

Cubase
,
1

I don’t know if this is a new issue of if it was already like that before, but I came across this :

The Snap Point isn’t taken into consideration when the Audio Track is set to Musical Time Base.
When changing the project Tempo (when Musical Mode is disabled), the Audio Event position follows based on its real start instead of keeping the Snap Point where it is on the Bars and Beats grid.

This is a real issue, as after changing the Tempo, we need to drag the Events one by one so the Snap Points snap properly to the grid again, where they belong. This is incredibly annoying.
If the Snap Point is at at Bar 10 where the verse begins, I want it to stay at Bar 10 even after changing the Tempo, that’s how it is supposed to work ! I don’t want the specific transient that is under the Snap Point to start from random places, I just want it to stay where it was so that the metronome clicks on it.

Click here to expand the animations

Short offset :
Time Base Tempo - Snap Point Bug

Long offset :
Time Base Tempo - Snap Point Bug 2

The thing is that it works as expected with other functions :
When the Audio Track is set to Linear Time Base, and the Ruler is set to Seconds, the Snap Point follows the grid properly, same as when switching the Event to Musical Mode (with Musical Time Base), the Snap Point stays at the same place and the Event warps around it as we change the Tempo.

So why is it defective when the Audio Track is set to Musical Time Base ?
Not only that, but the issue also happens the other way around, when the Track is set to Linear Time Base and Musical Mode is enabled on the Event, the Seconds grid will ignore the Snap Point and instead move the Event based on its real start ! I am utterly dumbfounded.

Obviously, if the Snap Point is already at the start of the Event, this is none of an issue, but there are use cases where we want to put it somewhere other than the Event Start, and that’s basically why the Snap Point exists…

Side note :

Please click here to expand the whole novel

I see it coming already, some people will start arguing about the meaning of what can be found in the user manual, because the way it is written can be completely confusing depending on where we read about the Track Time Base, although it describes the exact same thing.

Under Track Handling > Defining the Track Time Base is written :

Defining the Track Time Base

The time base of a track determines if the events on a track are positioned to bars and beats (musical time base) or to the timeline (linear time base). Changing the playback tempo affects only the time position of events on tracks with a musical time base.

This is the only comprehensible description of Track Time Base. It effectively determines if the Events follow the musical Bars and Beats, or the actual time in Seconds, when modifying the Tempo.

It means that if the Track is set to Musical Time Base, the Events maintain their start position on the Bars and Beats grid, while when using Linear Time Base, they keep their position on the Seconds grid.

Under Editing Tempo and Time Signature > Track Time Base is written :

Track Time Base

The time base of a track determines if a track can follow the tempo changes of a project that is set to tempo track mode.

In the Inspector for MIDI tracks, instrument tracks, and audio-related tracks, you can activate/deactivate Toggle Time Base to switch the track time base.

The following time base modes are available:

  • Musical
    Use this mode for material with a musical, that is, tempo-related time base. All tracks that are set to musical time base follow any tempo changes that you add on the tempo track.
  • Note
    For audio events on audio tracks that are set to musical time base, the tempo changes on the tempo track affect only the start position and not the actual audio.
  • Linear
    Use this mode for material with a linear, time-related time base.

First of all, this second description of Track Time Base is a total mess.

“The time base of a track determines if a track can follow the tempo changes…”

Determines if a “track” can follow the tempo changes ? What does that even mean ? It was previously talking about Events but now it is about “tracks” ?

“…of a project that is set to tempo track mode”

Why is it even talking about “tempo track mode” ? The Track Time Base behaves exactly the same whether the project is set to Fixed Tempo or Tempo Track Mode, so I don’t know what that means.
There’s no such exclusive functioning for “tracks” and for when the project is set to “tempo track mode”.

“All tracks that are set to musical time base follow any tempo changes that you add on the tempo track.”

Now this is even more confusing. Is that actually a typo ? Didn’t they instead mean : “All Events that are Set to Musical Mode follow any tempo changes that you add on the tempo track.” ?!

“For audio events on audio tracks that are set to musical time base, the tempo changes on the tempo track affect only the start position and not the actual audio.”

I read this note assuming Musical Mode is disabled, because it specifically refers to audio events, whereas MIDI events, on the other hand, have Musical Mode enabled permanently (see note below). And when Musical Mode is disabled (on audio events), changing the Tempo will indeed only “affect” the start position, and not “stretch” (speed up or slow down) the actual audio to match the new Tempo.

And that’s the critical part I don’t want people to argue about. The start position here only means the actual Grid position, not the real Event Start. The Snap Point is still supposed to take effect in this case.

Note : Musical/Linear Time Base on MIDI tracks actually acts like a switch for Musical Mode. MIDI events no longer adapt to the tempo when it is set to Linear, whereas Musical Mode on Audio events work with both Musical and Linear Time Base, which adds to the confusion.

2 Likes
2

The audio event keeps its absolute position on the timeline. The bars and beats positions change in time. It must work this way, since you turned musical mode off.

You need to turn musical mode on to make the event position follow musical (tempo) changes.

Bars and beats could not be the same position if you change the tempo. Tempo is a musical thing.

3

You’re not even trying to understand what I’am talking about. The issue has nothing to do with Musical Mode, but is about how the Events snap / follow the grid when changing the Tempo.

You contradict yourself with this statement.
The absolute position for Audio Events is supposed to be the Snap Point…

Bars and Beats are always in the same position, changing the Tempo is only a visual thing, the Cursor will scroll slower or faster depending on the tempo, hence the Audio Events get zoomed in or out, but the Grid will keep the same size, and Events must keep their grid position under any circumstances.

Try it yourself and you’ll see something’s not right. I did not take one hour to write down this issue for nothing.

4

I understand what you are trying to say.

No, not with musical mode disabled and showing bars and beats.
The musical mode is made for that situations.

5

Bars and beats are relative to the tempo information.
One bar will last longer with slower tempo.
If you deactivate musical mode, events will stick to their time position. They must stick to the time position.
If you change the musical tempo, it doesn’t do anything to the audio events positions.

6

Try it instead of negating everything that I say !

7

Once again you contradict yourself wtf !
Yes, they must stick to their position, so why do they stick based on the event start and not the freaking SNAP POINT ??? That is the whole issue !

8

They do stick to their position, no matter what you’re using for the position.
But the position is not related to any musical information.
So moving them to the bars or beats would change their time position.

I never saw audio events moving only by changing the grid type.
If you change the tempo and bars and beats are selected it looks like the events move, but they don’t.

9

Am I a joke to you ?
You are still not understanding what the issue is about, I have never ever talked about “audio events moving only by changing the grid type”, I really don’t know why this is coming into the discussion. I feel like you’re just saying random stuff without reading my posts carefully.
I will update the OP with animations so you can see it.

Or maybe you can do the experiment in the meanwhile : Take an Audio Event and place it so the Start is at Bar 2, and put the Snap Point at Bar 3. Now click the Tempo field and drag up or down to change it. You’ll see that the Event keeps its position based on the Start instead of the Snap Point. Is that clear enough now ? And please stop mixing up “bars and beats”, “time” and “musical information”, the issue has been explained very clearly at the very start of the OP :

10

The Grid does keep the same size ! Again my answer clearly explains how it works but you negate it. Musical Mode is in no way related to the Grid, the Grid is always fixed, it’s the Events that zoom in or out when Musical Mode is disabled to visually adapt to the Cursor moving speed. Why are you saying the opposite ?

If we enable Musical Mode, the Event keeps the same length for whatever tempo is set, because the Cursor will go through it slower or faster, so is the audio played slower or faster, but this still has nothing to do with the damn Ruler display !
:exploding_head:

Edit :
If you set the Ruler to “Time Linear”, it is indeed the Bars and Beats grid that stretches, and so do the Events. Maybe this is the setting you were using, hence the confusion between us two.
Nevertheless, this does not affect the broken Event positioning behavior when changing the tempo. Sorry if I seemed pissed off. :sweat_smile:

11

Actually, there’s Time Linear and Bar and Beats Linear for the ruler to further confuse communication. :laughing:

Going to try this now. I’ll be back.

Edit: Yes, it’s like you say, the snap point is being pushed around.

1 Like
12

Yes, but this is only a visual preference, it doesn’t affect the rest. For instance I use the default Bars+Beats Linear.

Thanks for coming to the rescue though :slightly_smiling_face:

13

For context, I think it works as specified in the manual.

14

Thanks for reminding what the Snap Point is :

Snap Point
The snap point is a marker within an audio event that can be used as a reference position.

The Snap Point page in the user manual makes no mention of the Time Base, so we may expect that the Snap Point takes effect as the reference position when changing the Tempo, as described in the Time Base page :

Defining the Track Time Base
The time base of a track determines if the events on a track are positioned to bars and beats (musical time base) or to the timeline (linear time base). Changing the playback tempo affects only the time position of events on tracks with a musical time base.

It says “Changing the playback tempo affects only the time position of events on tracks with a musical time base.”, because changing the tempo has no effect when the track is set to Linear Time Base. Please don’t be confused by “affects only the time position”, it does not mean the linear time in seconds, but the position in time based on bars and beats. I think you guys get confused by this one word/weird syntax.

Since the Snap Point is ignored when changing the Tempo when the Track is set to Musical Time Base (Musical Mode OFF), this confirms it is indeed a real issue.

Nevertheless, this also happens the other way around, as described in the OP.
When using Linear Time Base + Musical Mode ON, it’s the Seconds grid that will exhibit the Snap Point issue.

Cheers

15

It works as specified, agreed, but not taking the snap point into account is a major omission of the specification. It’s one feature fighting another here. Either the snap point matters, or it doesn’t.

It’s quite annoying though, I’ll give that to @Louis_R. I don’t use many SFX and other non-musical material (speech, ambience etc), but if I had lined up 10 tracks of these to specific measures and positioned them using the snap point and then changed the tempo only to find out they had been repositioned according to their event start (which is useless), I’d be pissed.

16

Indeed. I posted that for context, because the limitation of the feature is stated there.

image

…and not for other use-cases, i.e., tempo changes. Then, I suppose the “correct” thing to do is set the event snap point to the start of the event.

I’m not debating the point. (no pun intended!) But trying to offer some context as far as how to communicate this feature request.

17

Socratic style? With a seemingly innocent question, like:

Hey guys! I have a project here, all instrument tracks and one pre-recorded speech track. Now, I need a specific word to coincide with a big chord at measure 37. Using the snap point, I marked the word and aligned it to measure 37, no problem!

But then I found the tempo to be a little too brisk. I changed the tempo, but now my speech track is misaligned. Is there a way to set this specific moment of the audio event as an anchor, so that no matter the tempo the anchor will stay at measure 37 while the start and end of the event move accordingly?

18

Yes! It’s quite clear what one use-case might be!

19

To me this is a real defect that needs to be fixed, and not an actual “feature” that needs to be added.
If we spend a few minutes experimenting with the issue, it is crystal clear that it is the Snap Point that is supposed to take effect for positioning the Events. Just that it probably hasn’t been “developed”, just like many other broken stuff. It is clear that the developers haven’t pushed that far to implement the Snap Point thing, so that part is simply missing, but it’s in no way a “feature” to add, this needs to be resolved as a fix or improvement.

I cannot imagine the Cubase 13 release notes saying : “NEW : Changing the Tempo now uses the Snap Point for unparalleled positioning precision !” :laughing:
We should have it already.

Btw I have added animations in the OP.

20

But there is a history to it, an evolution if you will – I mean there’s a legitimate reason for the workflow, and as DAWs have evolved certain workflows become antiquated as software in general evolves – especially for new users – and a specific workflow may no longer be rational.

So I am suggesting phrasing a wish (for any feature request) in a neutral way, that’s quick to understand by someone who knows the software well.

Really, what difference does it make what term is used, whether it’s a defect, a feature, a missing feature, or a bug – the words have become less and less specific the more complex software becomes.

In my experience with SB, I have observed that they are interested in improving the user experience – and balance that with needs based on development resources etc., etc. So opening with statement like…

…totally works. Even though @ggmanestraki is being a little tongue-in-cheek, the message is short, simple, and easy on the eyes. It also might be relatable to less experienced users who might jump on to support the request.

It’s not so much proof that’s needed.

2 Likes