Hello guys!
I’m still learning cubase. Recorded a few clips at 80bpm. Then when I change any clip to a musical mode it jumps like that. Is it a bug?
Thanks
Hello guys!
I’m still learning cubase. Recorded a few clips at 80bpm. Then when I change any clip to a musical mode it jumps like that. Is it a bug?
Thanks
1 Like
This is a bug with the Snap Point, disabling preferences won’t fix anything, it has been tested thoroughly already.
Please see the following topics for full description :
2 Likes
I did. So if I start a new project, it works as expected. However, if I disable preferences and load my current project - no difference, it still jumps.
Good to know, thank you!
Observe that the snap point is set to 1.1.1.0 on the selected event.
I found that the unwanted moving happens also when you cut an audio event (snap points are both on the start position of the event), select any of the two events and switch it to Musical Mode. Cubase automatically puts the Snap point at the end of the original event’s end. It then moves the first event to end on the same spot as the second event does.
It’s probably the same root cause but you can’t even avoid it by carefully placing the Sanp point.
This…
becomes this:
1 Like
No, it put the Snap Point at the end of the new Event after making the split left to the original Event’s Snap Point, in which case the Snap Point of the original Event remains where it was.
By reading your post I think you don’t understand what the Snap Point is.
The Snap Point is the Snap Point, not the Event Start.
The link to this exact issue was already posted in my post above.
Ouch, that hurt.
I’m really sorry if I misinterpreted your description, but the order of the sentences makes it quite difficult to understand.
Why do you say “both” ? Is the parenthesis the situation before or after making the split ?
Does that mean the snap point is at the event start before enabling Musical Mode, and enabling it makes the snap point move to the event end ?
If the event jumps when enabling Musical Mode, it means it’s snap point was already placed at the event end prior to activating Musical Mode.
This is a pure matter of circumstances that the end of the left event lands at the same place than the right event’s end.
I have replicated this bug hundreds of times back when I’ve discovered it, and I have never experienced it the way you explained. If you think you found another way to trigger it, then please post videos or GIFS so we can see precisely.
Sorry for making false assumptions about you, you indeed know what the snap point is, and judging by all your other posts you are well experimented.
I’ll make sure this won’t happen again. 
After splitting the event I have two events. Each of them has its snap point at their start position.
Yes, that is what happens.
No, it wasn’t. You can see it in my screenshot (in the Info Line). Same applies to @shtreebun 's example video.
It is in the video from shtreebun. The snap point is at 1.1.1.0 before they switch the event to Musical, afterwards it is at 25.3.3.80, which equals the event’s new end position.
1 Like
Ok I see. I have no clue on how to reproduce this variant.
Perhaps the config files are corrupted and it interferes further with the initial bug.
Does that happen with a new project ?
I loaded my standard template and just recorded a mono track starting at position 1.1.1.0, I then split it at 2.1.1.0.
Maybe the track being mono makes a difference?
I can’t believe it ! When I was investigating the two main bugs months ago (both the Split bug and Musical Mode offset bug), I had actually found a third version but it was very complex with a lot of variables, I couldn’t reproduce it reliably. But now you say it, I have finally found the root cause of this third bug and can now make a detailed description, thanks to you guys ! I can’t thank you enough, this is the pinnacle of bug testing.
And no, that’s not the mono track, but I’ll come back in a few hours and post the results. 
1 Like
So this bug only occurs when the Event is snapped (via the Snap Point) at the Project Start (so the Snap Point needs to be at the Event Start), and when the Event Start has been trimmed (resized). These two conditions need to be met.
We can just call it “Resized Events that are snapped to the Project Start causes the Snap Point to jump at random places.”
What happens here is that by default, the Pre-Record Time is set to 1 second, so the Event is already resized when it appears on the track after recording.
If you start recording from the Project Start, the Snap Point is then placed at the Project Start, and now the bug is ready to get triggered.
If we toggle Musical Mode, what happens is that the Event slightly drifts to the right every time we press the Musical Mode button. Not only that, but the Snap Point effectively jumps to the Event End.
I believe that when the two conditions are met, the Snap Point is considered being at the Event End already, even if it appears to be at the Start, because when we Split the Event, it will apply the offset the same as I have already described in my older topics, the distance it will move forward upon toggling Musical Mode corresponds to the distance between the location of the Split and the Snap Point (in this case the original Event End). And since the original Event had its Snap Point at the end, every Split will cause the resulting Events to have their Snap Point at the end and triggering the Musical Mode bug, just like a chain reaction :
Now go back to the beginning and look what happens then we trim the Event End. Make sure to undo everything up to the recording so that the Snap Point is displayed to be at the Event Start.
However, it seems much more broken than I thought because the result shown with this latter experiment occurs regardless of the specific bug we are talking about in this current topic.
For example, if the Snap Point is placed in the middle of the Event, when resizing the Event from the right so that it goes past the Snap Point, the Snap Point will visually appear to be at the Event End since it is dragged along the resizing, but the internal offset remains, the same as when you make a split before the Snap Point !
Actually, the Snap Point position seems to be stored in two different places internally.
From what I understand, and it becomes obvious when reproducing the bug, one is for snapping the Event to the Grid – as displayed in the Editor – and will always work properly regardless of the bug, and one is used by Musical Mode – because when enabling it, the audio is stretched with the Snap Point being the center point, that’s what makes me guess that the Snap Point is stored separately for Musical Mode – and it is that one that seem to be bugged.
When we make a Split before the Snap Point, or when Resizing the Event from the right, the Snap Point value for the grid snap will refresh properly, but the one for Musical Mode won’t be refreshed, and keeps its previous value !
So what happens in reality is that when we toggle Musical Mode, the “Grid” Snap Point will try to snap onto the “Musical Mode” Snap Point, and since the two Snap Points always keep their relative offset, the Event will move forward like a caterpillar. An even better depiction is of turkeys running around a tree :
Apart from the turkey joke, this issue, I mean this group of issues, is downright appalling.
I have reported the main issue on Steinberg Support five months ago, and out of the 2 updates that were released subsequently, none have fixed it, and not a single word from a dev here on the forum either. This is completely astonishing.
According to older posts on the forum, this issue was already present in Cubase 10, and maybe it has been there for much longer ! I just can’t believe how such major stuff like this can’t get fixed rapidly, and most importantly how it could have gone on for so long without the dev team noticing, this right here being one of the biggest editing-related bug present in Cubase, if not the biggest.
At this point it really makes me question the way Steinberg administers its products.
Sorry for the rant but I think it’s deserved…
1 Like
Thank you Louis for your expert detective work. 
(How many beers would you say Steinberg owes you about now? )
1 Like
No problem Watson. 
I’d say, enough to stop ruminating on those bugs and get a good night of sleep lol.
Now I’m trying to do some creative stuff with this bug…
Nah, doesn’t work.
The new one mentioned here? Anything but position 1.1.1.0. Even moving the event by one tick to 1.1.1.1 fixes the behaviour.
2 Likes
Deleted