I also don’t understand why there’s a C# in the notes for Db7.
Dbb instead of C.
A# instead of Bb in C7
Fb instead of F
Yesterday, I corrected similar errors. After I got to the end of the song, the errors I had already corrected reappeared at the beginning. I had to do the same thing at least five times.
It also often happens that copied notes—that is, with exactly the same properties—are notated once with a staccato dot, then without, then again with, and then again without.
I could do whatever I wanted, but it wasn’t possible to add staccato to all the chords.
It is not always that simple.
I had luck. The space size simply decreased even further. At one point, it looked pretty good. Just a tad larger and the score image would be messed up again.
BTW
If a song title is too long, a line break occurs. The default font then cuts off a portion of the letters at the top and bottom. This forces me to use a specific font that’s narrower, so the line break doesn’t occur.
Another example of automation no one is able to comprehend.
Instead of displaying the actual note values, Cubase thinks to know better, how long my notes should be. To make things worse, staccato dots are now allowed to join the game. For me an articulation which should only be added manually.
I was told multiple times by Steinberg employees, that so many users give positive feedback for the new score editor.
I´m asking myself how that could be? There´s a random factor involved that delivers unpredictable, sometimes even plainly wrong results - in my opinion…
Who can be pleased with this?
Make sure you are showing signposts. You might have added system breaks before that are forcing breaks in specific places and now those breaks are no longer where you want. The signpost will show where the forced system break is. That could explain the reason for bar 14 taking up an entire system in your second post.
This is a known issue, unfortunately, and one that’s not easy to solve. The spelling algorithm that the scoring engine uses (based on the PS13 algorithm) takes a number of factors into account to establish a harmonic context and produce a ‘best’ spelling (for some definition of ‘best’). The algorithm needs to process all notes from the last key signature.
However, the score editor code tries to minimise the amount of data that gets reprocessed every time you edit, because if everything from the start of the project is reprocessed every time you repitch a note then that will be very slow. Unfortunately, this means that if you edit some of the accidentals then you may see others changing. This is because the score editor tries (in general) to only reprocess the content of the current bar, but this changes the harmonic context that the spelling algorithm uses, so it produces different accidentals.
We are still trying to find ways to improve this, but I wanted to explain why it happens. There is a bit of a workaround. If you switch to a different part or layout, then switch back then this will do what we call a ‘full sync’ that will show the true accidentals. So after you’ve made some edits and you want to see what the actual accidentals will be, do this trick and you’ll see the final result.
I understand that perfectly.
I’d also like to mention that the automatic correction of other accidentals in the measure often works very well:
If I change Cb to B once, the next Cb will also be converted to B. That’s very helpful.
Wish you good ideas with the repair of the backward correction!
