often I find that notes get unnecessary accidentals. In a piece in Bb for instance a Bb get’s written as A#, when there is absolutely no need for that.
or take this sample, piece is in Fm, so 4 flats. then a Eb doesn’t need any cautionary, it’s in the key. What happens in this example, first picture is of just one part. All is right. Eb notated as Eb, both in bars 26 and 29.
Now when I include the part before it, it’s wrong: an Eb gets written as D#. Why? This happens quite often, and I have to check all my parts for this, and manually set the correct enharmonic. What a job!
I have all ‘show cautionaries’ turned off. Experimented with the settings to no avail.
maybe because the D#´s are surrounded by E´s. That could be the reason, nevertheless it should not happen.
I had many situations where accidentals showed wrong at first, and once edited, they changed again when notes were added before or after. Something seems wrong with the rules for accidentals.
It is because of the default rules for accidentals. In general when you have a neighbor figure like D-C#-D you want to spell it as C# and not Db melodically. It is following the PS-13 algorithm described in this paper: https://www.titanmusic.com/papers/public/ps13-escom-paper.pdf
correct, but Cubase delivers two different versions in the OP´s examples, one with Eb´s, one with D#´s.
So are those rules you mentioned implemented, and if yes, how come we get different results?
And why does adding bars before or after alter accidentals at all?
Because it is continuously interpreting the choices of accidentals after every update. For all it knows, the person might not have even looked at the score even once, and they are just writing the piece in the piano roll completely and then looking at the score once everything is done. So interpreting which accidental it should be at the moment it is entered is not enough context, because the best choice of accidental will usually be based on what came before and what comes after. So if it got hard-“stamped” with an accidental that it chose by itself at the time of entry (ex. into the piano roll or with a MIDI keyboard) it might turn out to have been a bad choice when more notes get entered.
Manually entering notes in the score editor itself (ex. with the mouse) is a bit different I believe, I suspect those won’t get changed as they don’t get changed in Dorico, since if the user is specifying the spelling upon creation, it knows that the user wants that specific spelling. The same thing happens if you manually respell a note (with note name above or below) using the menu options.
I think it would be ideal if there was some kind of setting for each note to let the user control whether it is automatically spelled or what the set spelling is for that note, in the info bar of the key editor when the note is selected. A way to manually set the current spelling to be fixed and not changeable would also be useful (ex. if you could select a group of notes and set the spelling to something like “do not automatically change” which would in effect hard stamp those with the current spelling).
I’m not certain if Cubase does but Dorico does. If you enter with the MIDI keyboard it is different than entering with the computer keyboard or mouse, because with the MIDI keyboard there is no concept of spelling (C# and Db are indistinguishable), while with the computer keyboard or mouse you would actually choose C# instead of Db with the keys or by clicking. So the manual choice in Dorico is treated as a literal and it won’t change on you, while entering with the MIDI keyboard it has to guess what accidental you probably want using the PS-13 algorithm. Or when importing MIDI as well into Dorico, it has to guess the best accidental and it would use that same algorithm.
With Cubase theoretically it should be similar, if the note was entered in the piano roll it has no way to know what the user wants and so the spelling is unset and liable to change (unless you use one of the respell options). I would expect that if you entered the note in the score editor with the mouse it would be like Dorico where it would know you wanted that specific spelling and wouldn’t change it on you when you added or deleted notes later, but maybe it doesn’t work like this yet for some reason. I don’t use the mouse entry in the Cubase 15 score editor because I don’t find it particularly efficient.
yes, I’ve come across it by trial and error, and it was later explained to me in the lengthy posts below. scroll down to end of that discussion. My workflow is such that I play in parts using my digital piano, but after that I need to tidy up the score, since I’m not so precise about timing and note lengths while playing. That way I have total control over editing the notes, but when entered with the mouse it’s harder.
I disagree and think the book has to be rewritten then. The way cubase interprets these notes is simply plain wrong. The context is the key signature. In the scale of Fm there is only a D# if you want some kind of special effect (maybe a modulation to G#m). But of course the default is Eb, and there just cannot be any discussion about this.
In other pieces I have in Bb major I come across A#'s notated, for no reason!
The fact that cubase makes different spellings in equal situations is also very strange. Look at the key signature and you know you want an Eb here. That’s your context. The fact that including bars before the part in question is no excuse. Since I’ve entered a key signature at the beginning of the piece cubase ‘knows’ it’s Fm.
As for the documents you shared, they are too lengthy and technical. I’m a user who expects to see things notated musically.
Are there musicians working at Steinberg or just programmers?
Sorry if I sound blunt, but you just can’t defend notations like this.
The example you mention (D-C#-D) is really another story. The C# could be the leading note (tone) to D, or it could be a momentary lowering of the D (in which case I suppose a Db is better). There is ambiguity there.
Oh, you misunderstand me, I’m not saying that what it is doing is right or wrong in context, I’m explaining the likely reason for why the D# is appearing (I can understand the logic of the algorithm). From the documents I linked to, the original PS-13 algorithm as designed does not appear to be designed to factor in the key signature at all, presumably it is intended for situations like MIDI import where there is no key signature to begin with in most cases. It is probably trying to interpret the D# as some kind of lower neighbor to the E, the way it might in a situation in E minor or something like that. So I am explaining why it is probably doing that, not trying to say it is correct.
And the PS-13 algorithm I believe was introduced in Dorico years ago, but in Dorico what it does with it seems to be extremely limited in comparison, so much so that most users would never interact with it due to the way they use the program. As an example, most Dorico users would be entering that Eb not using a MIDI keyboard but using a computer keyboard/mouse and actually typing the Eb, which means it would be treated as a literal and not modified from this. And I believe in the case of Dorico, even with the MIDI keyboard, it gets automatically stamped with the accidental upon exiting note entry (if you’re doing step entry or timed recording in Dorico with the MIDI keyboard), as to my recollection I’ve never seen an accidental change later there all by itself in quite a few years of using the program heavily. So the issues could well have been in the algorithm for many years but because the algorithm had such minimal importance in Dorico the issues could never really have been noticed or complained about that much. Maybe users who imported MIDI into Dorico on a regular basis might have raised things at some point but that is a very small minority of users.
Cubase is a different story because now this algorithm seems to be much more front-and-center, as everything entered from the piano roll at least is processed by this algorithm (similar to a MIDI import in Dorico). So because Cubase users are interfacing with it on a regular basis, some gaps in it are starting to become apparent and should hopefully be addressed.
I see your point. To me it’s so natural to enter notes using a midi keyboard, looping a couple of bars and experimenting until I’m satisfied, a matter of letting creativity flow. Then I need to tidy it up of course.
I find it strange that this has never been noted, I suppose cubase is not the only application that’s using this algorithm.
I would like to report this as an issue. Maybe better in a new thread with a clearer example? Since Cubase does know the key signature, it could use this as an extra feed to the algorithm. Sounds simple I suppose it’s not.
Should I do this in a new thread? I would like to get it fixed, now I have to check all the parts in my score!
Based on previous threads for similar issues in the Cubase 14 timeframe, they’ve already changed the algorithm to factor in the key signature, but obviously that isn’t overriding the algorithm’s rule that a neighboring note should be spelled with a different letter-name than the note it is decorating. So this situation is a bit of an edge-case that might still have to be dealt with.
