Enabling musical mode causes events with Snap Points at the end to be moved away

There is an issue where activating Musical Mode on events that have their Snap Points at the end would cause them to be moved away from their original position.

How to reproduce :

  • Import or record audio
  • Open editor and put the Snap Point at the end of the event (drag outside and release)
  • Activate musical mode and notice the event being moved further away from its original position
  • Both enabling and disabling musical mode make the event to drift away

Additional information :

  • The distance the event will travel forward when toggling Musical Mode, corresponds to the same distance between the end of the event and the place you released the Snap Point from. For example, if you release the Snap Point 2 Bars beyond the event’s end, then toggling Musical Mode will move the event by 2 Bars.
  • Putting the Snap Point at the end by letting it snap automatically when you approach your pointer close enough (Snap must be active, J key), also makes the event to move away, although this is very tiny and you need to zoom in to see it properly. Sometimes it won’t do it but if you put the Snap Point elsewhere then “snap” it again it will eventually trigger the issue.

It has to be fixed along with this issue : Splitting an audio event before the Snap Point put the new Snap Point at the end of the event

1 Like

up :+1:

Why are people ignoring this ? This has to be fixed in next maintenance update.

Works fine here for me(?)

Top one is left/start anchor, second one is right/end anchor…

CBAnchor

Alright. Are you even on Cubase 12 ?
Because this is what it’s supposed to look like :

Yeah on C12.

But that example you’ve shown isn’t the same explained, it looks like you have trimmed a larger audio file but sent the sync point beyond the end of that event - and that’s what could be triggering this issue.

I’ll give that a try.

1 Like

Very strange, it’s doing it to me now. …But why wasn’t it originally?!

I even tried with the same audio file as before. Uninstalled C11 a week ago, so it was C12 that I used. I’m confused now!

Edit:
Ok, it seems the bug is, as you say, when you drag the [S] beyond the audio clip, if you let it ‘snap’ it seems ok. So that’s what needs reporting.

CBAnchor2

2 Likes

It does that whether your event is trimmed or not.
The greater the distance you release the Snap Point from, the bigger the jumps will be upon toggling musical mode.
If you release the S from one bar after the end of the event, then toggling musical mode will make it jump one bar. However, for some unknown reason, sometimes enabling musical mode will cause a short jump, and disabling it will cause a long jump.

Also, you said, “if you let it ‘snap’ it seems ok”. Did you mean when it snaps to the event end when you approach the pointer close enough ? If so then no, it is not okay. It may seem ok at first place but if you zoom close enough (just zoom in to the maximum) and you toggle Musical Mode, you’ll see that it will still move but it is so slight that you may need to toggle musical mode multiple times to see it jump one pixel.
That said, for some reason, sometimes the event won’t move away, but if you put the snap point elsewhere then “snap” the snap point once more, then it will eventually trigger the issue.

This is related to the Split issue whose link is in the first post. The latter interferes directly with the musical mode issue, they have to be taken in consideration as a whole.

1 Like

Is there a solution?

1 Like

To this day it still has not been acknowledged and reported by a moderator or a dev.
No one knows if it’s supposed to work like that of if it’s a bug. :grinning:
In the meanwhile, can you try reproducing the bug and confirm it ?
Thank you in advance !

Could anyone try to reproduce the issue and report here ?
It only takes one minute of your time guys.
This has been posted almost one month an a half ago and I got no answer from a moderator or a Steinberg employee.
This has been confirmed by only ONE single user to this day !
We cannot be the only ones having that issue !

1 Like

The bug has been present for more than two years…

2 Likes

Still not fixed in 12.0.30. :face_with_raised_eyebrow:

1 Like

Still not fixed in 12.0.40