hi,
why do I sometimes see this:
and in another song I see:
the note lengths are the same, display quantize in the instrument settings is the same. in both cases the notes are a couple of ticks longer than an eighth note, but why do I get different results? what am I missing? of course I want the result as in the second picture….
Michel
Hi,
Isn’t it related to the Display Quantize Setting?
I don’t use that (the DQ in the score toolbar) . Moving songs from C13 projects to C15 some songs show this behavior, and some don’t. Opening in C15 works fine, but when I copy the parts into a new C15 project (from a template with all the right score settings) some songs do this behavior. so maybe something settings wrong in my template? can’t find anything..
And anyway If in my instrument settings display quantise is 1/16 it should really never do this. All tracks are affected, or none. Strange but true.
Michel
It’s difficult to say why this is happening without seeing the project. Can you attach an example that shows the problem here?
after another 20 experiments I found that in Score Settings you have to leave the Fill Gaps option turned on. I don’t see why that is so important, but now I leave it turned off and everything’s fine. That’s the second strange setting in the score editor to keep an eye on.
(the order in which to set stuff in the Notations Settings is also important, which I mentioned in another post. I see no reason why the order should be of any importance, but that’s the way it is)
thanks for your attention anyway. Maybe someone can explain why the fill gaps setting messes things up, when it’s supposed to tidy up a score
Michel
but leaving Fills Gaps turned on isn’t ideal either, since it mucks up swing eights that are on the beat and followed by a rest:
shouldn’t really do this I suppose
Michel
Hi,
Would you mind to share a project (snippet). Just these two bars, please.
thanks for the attention.
I enclose a tiny project which to my surprise shows more strange behavior, but it could also be a clue.
the altsax1 track was created in C15 and shows the correct notation. But I can’t reproduce that anymore! It keeps on being wrong whatever I do.
the altsax2 was created in C13 and copied into C15. The notation is off
all the settings are the same as far as I can tell.
turning on Fill Gaps in the score settings makes everything right, but I don’t want to use that because I’ld have to check all my scores where cubase thinks it’s necessary to make the score more readable. I want control over those gaps, I write them purposely after all…
the notes have been quantized and length quantised in a swing feel. So eighth notes on the beat are a bit longer. But this shouldn’t be a problem, it never was in C13 anyway.
why are the two tracks different? do you see that?
Michel
probeersel.cpr (185.4 KB)
Hi,
I can replicate the issue with your project:
I double-checked, the length in the Key/List Editor is exactly the same for altsax1 and altsax2.
@PaulWalmsley , do you have any idea, please? Thank you!
This morning I discovered that inputting notes with the mouse and than applying swing quantize gives the correct notation result.
Inputting notes with a pianokeyboard and then applying swing quantize gives the wrong result.
this also worked in projects that are a mess notation wise, apparently because everything was input using a piano keyboard. with the mouse it’s a neat result.
also found that in Instruments settings choose a fixed value for display quantisation in stead of an automatic value makes it look good, but…. now the tuplets are a mess. useless.
I fail to see why there should be a difference.
Michel
I’ve looked at this file and it has exposed a bug when Fill Gaps is turned off where the note length doesn’t take the quantization unit into account. In this case the note length is 7/12 of a quarter note (0.5833) and this gets rounded to 9/16 of a quarter note, which is 1/8 note tied to 1/64th note.
I’ve fixed this for the next update, which will also have improved behaviour for Swung tuplets.
brilliant!
Can’t wait for the update, but for now I can just ignore that it looks awful and expect a better result in the (hopefully) near future.
strange though how keyboard input and mouse input give different results as described above
thank you @PaulWalmsley
Michel
