Whenever I open the new score editor, there´s a new annoyance… 
Key is F# major (B lydian), but the E# of this key is displayed as F natural. There´s nothing to discuss, it´s wrong programming, when notes within a key are not displayed correctly!
I agree. Although I never use key signatures myself (the types of things I write never call for them), I was a little concerned about this impact potentially when the “smart” enharmonics handling was removed as per this thread:
I do not have the old 14.0.20 version of Cubase 14 to test with anymore, but I suspect the old smart enharmonics system would likely have handled this situation correctly.
I suspect getting correct enharmonics from a piano roll (raw MIDI data) is not necessarily a simple task. Enharmonics systems would typically need some “intelligence” at least for situations like this with a set key signature. So this system would need to be a somewhat smart system to factor in the key signatures to begin with.
However, users were clamouring for a completely dumbed-down system instead of a smart system, and that is now what we have.
three rules, that should do it:
- for notes within a key, don´t use accidentals
- for notes out of key use the more probable accidental, for example G# over Ab in the key of C major
- once editied by the user, accidentals must not be changed anymore by whatever happens to notes nearby
of course the program must have all the information implemented, which notes are in and out of a certain key, and how to handle out of key notes. But that is not a huge package of information and should not require “smart behaviour” or machine learning or what not…
It´s just something like:
When in key C major use C D E F G A B + C# D# F# G# and Bb
repeat for every key
Just because E# is a somewhat rare note, it´s the correct note in F# major and therefore should be displayed!
I´m afraid I have to repeat myself again: the old score editor could do this flawlessly
1 Like
I’m not talking about machine learning - but anything that makes choices based on a key signature has to be somewhat smart. People had been asking for a system that was not smart at all. “Smart” doesn’t mean machine learning.
In my case, this will frequently give wrong accidentals (most of the time), due to the large frequency that I use the chords Db major, Eb major and Ab major within C major (as borrowed chords from minor due to modal mixture). In my case I would want some more intelligence to help with this.
Another issue is that there should be a way to distinguish “no key” from C major / A minor. Most of the things I’m working with won’t be using key signatures at all and I don’t want to have to respell a zillion accidentals each time because it is getting them wrong, so for me, a smarter system is better, actually.
From testing just now, the old score editor seems to use an even smarter system than you describe. It recognizes triads within the part and tries to keep the spelling of them to thirds. So instead of spelling Bb C# F (as though it were following your ruleset exactly) it will use D-flat in this case. So it properly tries to spell vertical intervals as thirds - that’s a rule in addition to the ones you listed.
Actually the new score editor already does these things too, so they just have to get it to factor in the key signature.
It seems like they did an override to avoid the E#, so even though Cubase 14 Score Editor is trying to spell triads too, it doesn’t in this particular case where E# would be involved:
This suggests that the logic that tries to get an F natural instead of E# is overriding too many of the enharmonic rules.
good point for additional rules, especially when triads and thirds come into play!
How to handle non-key notes is debatable, and there will never be one way that fits every time. But at least the in-key notes should be recognized and displayed correctly. That should not be that hard to implement…
I was thinking about the no-key situation, too.
It´s probably impossible to make too many specified rules, because anything can happen here 
Maybe a global “avoid double flats and sharps” is all that´s appropriate.
A “apply accidentals edited by the user throughout” rule, or something like that could avoid “F# here, Gb there” situations.
Voiceleading should be taken into account, too.
G->Gb->F is preferable instead of G->F#->F
F->F#->G is preferable instead of F->Gb->G
Maybe an additional “no key”-key with different rules than C major could included in the list of keys.
1 Like
Dorico actually has had this from the beginning, and it is the default key (atonal). I’m not sure how this was handled when the new score editor was brought into Cubase though, as I think Cubase traditionally has not had this.
Yeah, from my experiments it does seem to be taking voiceleading into account still in this regard, because it is spelling chromatic passages correctly in Cubase 14.
You’ve clearly described a bunch of the principles involved here, but the issue is always trying to give these rules to a computer - I’ve done a lot of programming in the past and when you give lots of rules like this, the order/sequence matters a lot, and making exceptions for certain things can matter a lot. A deceptively simple ruleset can easily become more complicated in reality than it might seem, when provided to a computer that takes all directions quite literally without analysis. There can be all sorts of corner cases that you didn’t think of until you encounter them and see it doesn’t handle them properly. A seemingly small task can easily become a much bigger one.
We got very clear feedback from a number of users that they never wanted to see an Fb, E#, B# or Cb by default. Or double sharps or double flats. We responded by making that change. We now get complaints from users that they do want to see these.
We made the change to prevent automatic Fb/E#/double sharps etc in the 14.0.30 cycle. We received no feedback from beta testers about that, so it stayed that way for the release.
I have now added exceptions so that key signatures with 6 or 7 accidentals will be spelled as you expect.
Please be mindful that there is a team who listens and respond to feedback. Please be respectful of that.
Paul, when the score editor delivers notation, that is against established music theory, then there´s a mistake in the code! Very simple and by no means disrespectful!
E# for example is a somewhat rare note, but it´s there for a reason.
The user complaints derived from the random appearances of double flats und double sharps, that made no sense at all. The solution can not be getting rid of all exotic accidentals, because sometimes they are correct. I guess there are experts in your team that are aware of music theory, so please use this knowledge to the highest degree possible.
2 Likes
Hi Paul,
notation things shouldn’t be implemented based on user feedback, but rather on good/sound knowledge of music theory.
And, as with all music notation things, the user should always have the option to override rules. It’s not appropriate to enforce rules against the user’s wishes.
1 Like
Both @Synthplayer and @r.u.sirius, I must urge to refrain from personal attacks.
We are trying to build a useful tool for a wide variety of use cases. We are listing to feedback in order to understand how user facilitate the various options they’ve got. You have brought up reasonable use cases that warrant further changes, which will be available in the next patch release. However, it’s not OK to claim “wrong programming”, assume what’s “smart” or “simple” technically, or what is or isn’t “simple to implement”.
We are happy to engage in kind feedback. The conversation above is a poor example of that.
2 Likes