Moving a folder track breaks contained signatures

Der Cubase-Team,

I have found the following critical bug in Cubase 12.0.70 Build 464:

I have a signature track contained in a folder track.
When I move the folder track, the signatures are “quantized”.

cubase-12-bug (4)

Many thanks for fixing.

Bug-Report.cpr (98.5 KB)

I struggle with reproducing this behaviour on PC.
When I move the folder part the signature events don’t move at all. I also don’t know how to get the little diamnod symbols on the signature events.
Clearly I am missing a step or two.

Edit: Oh wait, I got something. It highly depends on the position of the signature events and the position of where one drops the part.


The problem is the 2/4 bar. If you move it behind the 2/4 then the issue appears. Obviously Cubase counts, by how many bars, beats, ticks… should move the content.

1 Like

What precisely should be fixed though? What exactly is the “bug”?

In any case, it’s not possible to see enough detail in the animation, such as bar numbers.


I can see it. There is nice Zoom to the ruler before the moving of the events. The trick is, you have 4/4 bars and one 2/4 bar and again 4/4 bars. Then you move the events behind the 2/4 bars. In this case bar 16+.

1 Like

What is the bug though – Or, not a bug?


The bug is: In this special case the frame showing where the events will end up shows, the events will be moved to bar 17. But once you release the mouse, the moved events end up at

So either Cubase should show this before you release the mouse (so the frame should be placed at or the events should end up as the frame shows (


I don’t know. There’s a lot going on here. In my opinion, it’s an exploit.

If you go and put a signature track in a folder. and then close the folder, there is no data part on the folder to allow us to move the signatures.

However! Once we sneak a MIDI track in the folder, having created a part for it, this will make the folder show a data part. If we move that part, all hell breaks loose. Because the signature events ALSO move with the part (in my opinion they shouldn’t), and what’s more, the MIDI part is dropped after it has been dragged a number of beats later. But this number of beats might lead the part to not fall on a bar’s one, ok, this doesn’t matter much, but it does matter to the signature events, that are forced to move around in order to be in proper places.

Well, if someone made sense of what I just wrote, my congratulations. :laughing:

I believe signature events and MIDI parts were not meant to move together. In this case, we can move them, but I feel we shouldn’t be able to move them.

It’s a fairly easy issue to study though. Just put a signature track in a folder, start creating signatures, one per measure. 4/4 one bar, 3/4 one bar, 2/4 one bar, 1/4 one bar, 7/8, 6/8, 5/8, 4/8, 3/8 all one bar each. Move them around, everything’s fine right? Then create a MIDI track, draw in a MIDI part, stash it in the folder too. Once you drag the “compiled part” of the folder to a specific place that would NOT be the one of any bar, the part goes there, the signatures freak out trying to make sense of where they’re allowed to be, and finally the part ends up in the “wrong” place (compared to where it was supposed to go just before letting off the mouse button for the drop).

Just don’t allow dragging time signatures along with MIDI, or if it is supposed to be allowed as an operation, it should function as Insert Time instead?

Actually, scratch that. I don’t know what’s going on. This is something that happens even without a folder. See here:

Let’s move everything one bar later.

Problem one: I can’t drag the signature events and MIDI together. Once I do, only the signatures move.

Ok, let’s do it one step at a time:

  • The successful way:

Fist move the signatures one bar to the right.

Then the part.

OF COURSE, this is logical, if you consider that once we move the 3/4 signature from bar 1 to bar 2, the initial 4/4 takes over bar 1, adding an extra beat. That’s why the MIDI part ends up on the 4th beat of the previous measure. But at the time, when I placed the part, I was sure that it was placed at the very start of a measure, thus, when I place the signature right at the start of the MIDI part, I expect it to stay there. But the debt of 1 quarter note to the previous measure kicks in, so the signature is placed 1 quarter late from my point of view.

But I don’t know, maybe it’s the reptilian brain or something, I feel that bars should be eternal. You know, a bar is a bar. No matter if it’s 3/16 or 6/4. Altering a bar should add time if needed, or cut time, but a bar should not distrurb its neighbor. Obviously it doesn’t work that way right now. Whether it should, I guess is up for discussion, but I’m guessing that there’s no bug here.


I can confirm this.

I agree with this one.

This is what you know, but Cubase doesn’t know, you want to link the MIDI Part with the Time Signature event.

1 Like


In my opinion, things work fine as they are. Maybe if we want to move whole sections around (time signatures and all) without much trouble we should “Insert Bars”.

But, this expectation of “Bar priority” if I may call it so, would be akin to having a whole section in 4/4 like so:

|x - x - x - x -|x -x -x -x -|

then we changed the time signature to 7/8 and the section became

|x -x - x- x|x - x - x - x|.

The bars are essential building blocks of arbitrary duration then, and their content is interpreted measure by measure. Of course it’s a wildly different mindset, I’m just bringing it into this discussion, because that’s the thing that is implied if we want to park a MIDI part at any start of any measure and expect it to line up no matter what changes occur in the time signatures.

Hey :slight_smile: Thanks for looking into this! The issue also happens if grid alignment is set to bar.

In my case this should not be a problem at all.
When cutting and pasting the part on the folder track, the issue does not happen.

I suppose Cubase starts counting beats at the start of the project, and places the measures as dictated by the time sigs as it iterates through them along the timeline.

That can result in things that look weird or unexpected, but arithmetically speaking are correct.

Or am I off beat here?

1 Like


No, I think that’s exactly what’s going on.

1 Like

I suppose Cubase starts counting beats at the start of the project, and places the measures as dictated by the time sigs as it iterates through them along the timeline.

Does that also explain why moving the part with the mouse produces a different result than copying and pasting?

I don’t know what your snap settings are, so I don’t know.

I do. I looked at their GIF.

Okay, I downloaded the project and checked it out.

Of interest might be that this is the same behavior in C11 and C10, but in C9 the sigs don’t move with the folder part.

In my test,

  • If you nudge the folder part one bar at a time it is correctly calculated
  • if you copy and paste a selected range of the folder part it computes correctly.

I wouldn’t consider this critical since it doesn’t crash the program, and there are a couple of workarounds.

I wonder also if an error that has existed for 5 years has been reported before or is this workflow so seldom used that the OP is the first to discover?

@gracecloud I’m curious to know if this your active desired workflow? Or have you revealed this bug through experimentation?

Is it a case of wanting to move sections in time to keep sigs and tempo with the audio and midi. as in having a film’s cues all along one timeline?

1 Like

I explored this bug while developing a workflow for my live show. As a keyboarder I have organized all my songs in Cubase. To quickly rearrange songs I put all tracks into folder tracks. Doing so, I can easily reorder songs along the timeline by just dragging and dropping the parts on the folder track.

While doing so I realized that the time signatures contained in a song get broken.
The ugly thing on this bug is, that this is not obvious.

I see! I had not thought of that. I don’t work for Steinberg, but I can add a report to the developers.

In the mean time, what is your workaround?

While it’s a different approach the Arranger Track might be of interest – it’s designed for this use.