I believe that’s a bug, but let me know if I missed something.
Download the following project: MIDI quantize issue.cpr (189.2 KB)
It has a single MIDI track with a single bar of music.
Select quantize settings of 1/16, select all the notes and hit quantize. For some reason, even though all notes are already aligned to the grid, Cubase decides to move some of the notes 1/16 back.
See the following gif for demonstration:
Is this a known issue? Am I missing something? Is there a workaround for that?
Update: I’ve found a workaround for this: if you cut the MIDI notes and paste in place (Alt+V) it seems to resolve the issue. Still seems like a bug.
It’s not a bug, but it is annoying as hell. Cubase seems to remember the original position with certain settings and it’s hard to get it to quantize like you’d expect. Have to bounce it or something. I’m sure somebody can explain it better than me.
I cannot reproduce the issue.
Also your project file is blank, there’s no midi event in it, we have to add it manually then the issue won’t occur.
On your side, is the issue still occurring ?
It’s not a bug as far as I can tell. Quantize MIDI is a non-destructive operation. That means that Cubase doesn’t permanently change the MIDI events when you quantize, it’s more like a layer on top of the original events. This means that when you use Reset Quantize, the MIDI event is reverted back to the original recording, or the quantize layer is removed if you will.
It also means that every time you quantize, it applies it to the “original” event, not the last quantize.
Example:
Record a sloppy performance
Apply 1/16 quantize
Quantize is applied to original recording
Apply 1/8T quantize
Quantize is applied to original recording, replacing the previous quantize.
Whaaaat
I did not know that!!
That will explain the issue. I will try to reproduce.
Is there a way to override this behavior and change the actual position of the notes?
As a side note, most operations in Cubase nowadays are non-destructive. Even when using Offline Processing on audio events, you can revert back to the original.
My bad I’m sorry, the project opened with the locators on bar 88. How confusing.
The notes internal data seem to be offset/corrupted in the project file.
Why do I say that ?
Because if you select the notes and modify their length or move them, it will fix the issue.
Doing so will update the “wrong” internal values to the correct grid values.
Since the note data was not the same internally as it is visually on the grid, applying quantize would do it on the “wrong” grid.
Once you did that, the issue won’t occur anymore even if you Undo all the changes.
Saving the project will then fix it.
However, if you close the project without saving and open it again, then the issue will be back.
Your issue was just a random and rare data bug/offset. Since it cannot be reproduced from a blank project reliably, it is not an issue. Just bad luck.
Or maybe it is related to Tempo or something like that but again, this happens very rarely.
This post was marked as the solution but I don’t don’t think it is one.
The OP original problem was the notes not being quantized to the right place when hitting Quantize, most likely because the notes data had an internal offset. I tried my best to explain that in my post just above.
We have the same problem. Quantize behaves identically to Reset Quantize instead of moving the notes to the grid selected in the Quantize menu. If this is a ‘Feature’, then I have a few more ‘features’ to report! In my view, Quantize of an already previously quantized selection should override its quantize history by one iteration, such that Reset would take it to the last status.
Record sloppy note
Quantize note to desired grid
EITHER Reset - reverts to sloppy note OR Quantize note again to a different grid - should move to the new grid, not perform a reset to the sloppy note
Current workaround, Freeze Quantize as suggeted above, and then Quantize anew.