Decreasing naturals and sharps in key signature change appear in the incorrect order
Just come across this whilst transcribing Guilmant's Andante.
The key changes from E to E minor. MuseScore gives this as the key signature:
I couldn't understand why it looked wrong until I realised that the original had:
According the MPA document found here: http://icking-music-archive.org/lists/sottisier/notation.pdf
Naturals should follow sharps when changing to fewer:
This behaviour was first noticed in 1.3 but is also there in MuseScore 2 build a32e5b3
I'm running Windows 8 Pro
Attachment | Size |
---|---|
Keysigwrong.png | 31.36 KB |
Keysigcorrect.png | 52.99 KB |
Keysigorig.png | 61.46 KB |
Comments
I went digging through my piles of male choir choral music looking for examples. Almost all do the correct thing of simply changing the key when they go between sharp/flat or showing the cancellation when going to C. Very few actually show the accidental cancellations between sharp/flat. I could only find one that did the cancellation going from 5 flats to 3 flats, and it was done backwards.
The MPA guide says that if key sig goes from sharps to fewer sharps or flats to fewer flats. The naturals are after.
But for flat to sharp, or sharp to flat, the naturals should be before.
I wonder what "Behind bars" says about it.
For what is worth, it seems Sibelius default to no cancellation at all!
Actually, it says that you don't need to show the cancellation at all, unless you are going to C. Most of the examples I went through had no cancellation between key changes except for going to C. Most of the other apps (Finale, Sib) have the option to show/hide the cancellations so Sib likely has the option to hide this enabled.
Sibelius does the cancellation when returning to C indeed.
I'm looking at page 92 of 'Behind Bars' - it mentions older editions displaying the naturals after the new signature, to preserve the 'cycle of fifths' arrangement. The standard is for the naturals to come before the new key signature.
I don't consider this a bug - perhaps a feature request to account for such scores?
"The standard is for the naturals to come before the new key signature"
Not according to the Music Publishers Association of America.
I realise, now that you have mentioned the cycle of fifths why it looked wrong to me.
The order of sharps and flats is drilled into instrumentalists during their training, in order that they recognise key signatures at a glance.
Consequently, any system which deviates from that is going to look "wrong" and thus confuse.
I would, therefore, suggest that Elaine Gould is wrong on this point.
The fact that it is used in "older" editions means it is an established standard, and changing it would seem to be a nonsense.
I should clarify that she says "some older editions (including nineteenth-century French editions)".
While the MPA may claim it as their standard, and it used to be used, doesn't make it so now. Most of the time you will either not see any cancellation and just have a straight key change, or you will see the full cancellation (to C) or the full cancellation to a new key. I've never seen the usage of the one the MPA recommends, but have certainly seen the "incorrect" one more than once. I find it easier to read because you can skim right past the cancellations and read the new key sig as they are not blended together.
You're argument about the circle of fifth's doesn't make sense. If I see the mixed key/cancellation in the proper arrangement like a proper keysig, my first thought is the arrangement is the new key, and not just the remaining accidentals. Seems easier and consistent to see what's cancelled, followed by the new key as it would be shown for almost all other key change cases. Why change the order for just these cases?
First of all MuseScore too has the option to hide naturals in key changes. It is not global but on a per-key sig basis:
1) Select the key sig
2) Look at the Inspector!
Second, I totally agree with ChurchOrganist (#6 above ). The screen shot at the top does look 'wrong'; I do not have my sources at hand at the moment, but I'm quite sure that, not only the MPA, but also Ross, Stone and -- I think -- Powell all agree on this. So does a corpus of music published in the last two centuries at least. Ah, Artusi, Artusi...!
M.
I'm late, but number 3 makes sense to me. http://musescore.org/en/node/20724#comment-77424
OK so we have 3 options apparently
1/ Naturals are always displayed before. This is the default of MuseScore 1.X, Lilypond and Finale.
2/ Naturals are displayed after key changes if music goes from sharps to fewer sharps or flat to fewer sharps.
This is MPA recommendation, not implemented by default in any scorewriter (?)
3/ Do not display natural, except when going back to C major / A minor.
This is the default in Sibelius.
I suggest we adopt the default in Sibelius.
If the user requires the display of naturals, they should then be able to choose whether before or after, according to the standard they are following.
I am about to post a code pull request which implements a score style to choose the position of naturals in key signature changes. The style is score-wide not program-wide, meaning that different scores can have different settings.
The 3 settings described above are implemented. Default is No Naturals (with the exception of a change to CMaj/Amin). Old scores (<= 1.3) are given a default of Naturals Before to keep the same formatting. Some screen shots: None, Before, After respectively:
NOT FOUND: 1
NOT FOUND: 2
Any comment?
M.
Excellent work Maurizio :)
Looks good! How will the UI work? a combo or a radio button? in a new tab?
Currently, I have added a triple radio button to the "Accidentals" tab of the General Styles dlg. Radio buttons allow lengthier descriptions and easier comparison between them (differences between the three options are somewhat subtle).
Of course, the UI can be improved, once the framework is in place.
M.
How come the 4'th measure of the second and third test files (change to Eb) show the same order of naturals/accidentals?
Because there is no doubt that naturals come first when changing from a sharp key sig. to a flat key sig. or vice versa. See posts #2 and #11 above among others.
M.
Right, I missed that part.
Should be completed by merging https://github.com/musescore/MuseScore/pull/368
Please re-open if there are other issues.
M.
Automatically closed -- issue fixed for 2 weeks with no activity.
I'm happy to submit a new issue if people would rather, but for now, I'm lazy...
I love having these options. However, with the default being to not show naturals except when changing to C/Am, this puts us in a situation where you cannot easily force naturals to display, because the right click menu still says "Hide naturals", and no amount of toggling that will cause naturals to display unless you first go in and change the style setting to permit it.
I'd expect that if the default is to not show naturals, then the context menu would initially say "show naturals", not "hide naturals", and it would actually work :-)
Looked at another way, I see the first two options in the accidentals style as just affecting the initial state of an added key signature. The third option is kind of a separate deal, a checkbox as opposed to a radio button, that controls the actual order of the naturals when displayed under either of the first two options.
This now appears to be fixed.
Can anyone else confirm???
No I can stil l reproduce. Create a score, add a 6 sharps, add 3 flat. Right click the 3 flats, Hide naturals is shown (they are no naturals), click it twice, no naturals appears...
I think the problem is more with the UI than with the code base (well, of course the UI is coded in the code base...):
When the score defaults to "Only to CM/Am", the "Hide / show naturals" in the key sig menu seems to make little sense. One solution would be to remove this menu item when that setting is activated.
On the other hand, the hiding or showing of naturals remains an inherent property of any key sig, regardless of how it is actually drawn. So, the menu item should remain, after all. Maybe the right compromise is to gray it out, but leave it visible?
I can quickly provide a PR in this sense, in case.
Thanks,
M.
The PR is here https://github.com/musescore/MuseScore/pull/780
Maybe it would make more sense to keep showing the menu but make it work like Marc explained here http://musescore.org/en/node/20724#comment-85196. Meaning if the natural are shown, give a way to hide them, if the natural are not shown give a way to hide them.
Not sure to which of Marc's comments lasconic refers (the link goes to the top of the page), but I assume that it is #22.
There, Marc says two different things:
1) Use the "hide / show naturals" contextual menu command to override in both directions the general style setting (which is not what the command is doing now). This is apparently what lasconic is recommending.
If the naturals style is set to "Only to C Maj / A min", I wonder what sense would have to give the ability to show them occasionally. It would be then cleaner to simply suppress this menu command when this option is selected.
Note that this is different from the current situation (which was designed when the naturals were always shown), as there are obvious occasions when one needs to hide naturals which would be otherwise shown -- for instance at the beginning of a second movement of the same piece in a different key --. But I cannot think of obvious occasions for the opposite.
2) Change the difference between the 2nd and the 3rd current options (natural after or before) into a check box applying to both cases "naturals only to C Maj - A min" / "naturals always".
In my opinion this is not correct: with the first option is selected and there is some sharp or flat, naturals do not come before or after, they simply do not come at all! They are only shown when going to C Maj / A min, i.e. when there is no sharp or flat; so, when option 1 is selected, they can never come before or after something else.
The current arrangement of three options seems to me the clearest and cleanest solution. Just my opinion, though...
M.
Fixed in 9da8698926
Automatically closed -- issue fixed for 2 weeks with no activity.