MS 2.0.1 - Inserting Open/Atonal key sIg doesn't cancel a previous key sig
First of all, this being my first post here, I would like to offer a HUGE thank you to all the developers of Musescore, and especially Musescore 2 (2.0.1), which I'm finding to be an absolutely brilliant piece of software!
I'm currently migrating some old scores from Finale and SIbelius and for the most part it seems to be a breeze. However, I did just find one problem (I tried searching the forum but this problem doesn't seem to have been reported before):
The Open Key/Atonal Key sig in the pallette is a great idea, but if inserted into a score which already started with a conventional key sig, it doesn't seem to cancel the accidentals from that previous key (as inserting any other key sig would), which is unexpected behaviour and causes a problem both in the score and in any transposing instrumental parts. Is this a bug?
I'm running Musescore 2.0.1 on Windows, in case that's of any relevance.
Many thanks in advance.
Comments
Which palette is the open key/atonal key sig in? I can't find it in mine (2.0.1 ubuntu, build 9e84592).
In reply to Which palette is the open by underquark
Key signatures palette in the advanced workspace, the last one, with the x in it
In reply to Which palette is the open by underquark
You're probably looking at the "Basic" palette. It's in the "Advanced" Palette (see https://musescore.org/en/node/36121).
If I understand you correctly, it *should* work, and does for me. Can you attach the score you are having problems with and precise step by step instructions to reproduce the problem?
1] I had a Custom palette open so couldn't find the Open/Atonal Key Sig but I also couldn't find it in the Master Palette
2] My not finding the KeySig aside, had you already entered the notes and then add the Open/Atonal KeySig into the existing score? If so, then the pitches of the notes won't change if they've already been entered.
In reply to 1] I had a Custom palette by underquark
If my "Master Palette" you literally mean View / Master Palette, it should be there. If you don't see it, perhaps you still a very old palette left over from a nightly build from the fall? Seems hard to believe. Or maybe somehow you delete it from there?
Anyhow, adding this or any other key signature should not change any pitches, but it *should* change the spelling of notes, adding / removing accidentals as necessary. For instance, if you you original had a D major key signature and had music with an F# (no accidental required) and C natural (accidental required), then you insert an open/atonal key signature anywhere in from of that passage, it should add the sharp to the F and remove the natural from the C.
In reply to If my "Master Palette" you by Marc Sabatella
@Marc & underquark - thanks for your replies.
I understand how the Open/Atonal Key signature works. What I am suggesting is that, in the scenario you (Marc) give as an example (i.e. a score starting in the key of D Major and subsequently inserting an Open/Atonal Key sig), the key change should be explicit (i.e. in this case, two naturals, F natural and C natural should appear, exactly as they would if the change were to a C Major key sig instead). At present, this is not explicit (since no cancellation naturals appear when inserting an Open/Atonal key sig), and anyone reading the score might be lead to believe that we were still in the original key. Even though accidentals on individual notes after inserting the Open/Atonal key sig would cancel out those notes in the original key, I feel there's still the mindset when reading that we're still basically in the original key unless and until we see an explicit change of key signature.
Of course, from the point of view of a lead sheet or score with no transposing parts, I could just insert a C Major key signature instead. The problem with this in a score with instrumental parts though, is that it would give any transposing instrumental parts a corresponding tonal key signature, i.e. a Tenor sax part would change to D Major (two sharps), which I definitely don't want. When I insert an Open/Atonal key signature into a score after a previous tonal key signature, I want the score, and all transposing instruments to move explicitly from that tonal key to open key (i.e. no sharps or flats either in the score or any of the parts) AND to do this by inserting an explicit cancellation of any previous tonal key signature immediately beforehand in order to make the key change as clear as possible.
I can send a score if necessary, but in fact this is easily reproducible - just start a score in (e.g.) D Major and subsequently insert an Open/Atonal key signature. You'll see that no cancellation naturals appear immediately before the key change, as they do if you insert a C Major key signature instead.
In reply to @Marc & underquark - thanks by Xasman
Oh, I see, you aren't talking about accidentals on the notes, but the display of the key signature itself. You're right, they don't appear, and should. The case of someone wanting to change from a "regular" key to an atonal one was not considered. Should be possible to fix.
But FWIW, the way it is implemented, an open key signature is just a custom key signature (created via Shift+K) that happens to contain nothing. You could create your own that happens to contain natural signs and it would work about the same. It just wouldn't transpose the naturals. Hmm, I mean, for Bb instruments, you might have a change from D major to atonal in concert pitch, which is E to atonal at written pitch, but your custom key sig would have 4 naturals (or however many you added) in both cases. Still, not a terrible workaround for now.
Issue created: #63711: No naturals appear for change to open/atonal key signature
In reply to Oh, I see, you aren't talking by Marc Sabatella
Thanks Marc, that's helpful, and no it's not a terrible workaround, but it is messy and (IMHO) shouldn't be necessary - it would add quite a bit of editing time to scores with several transposing parts and lots of these types of key changes. Transposing the key-cancelling naturals automatically for transposing parts at the same time really is crucial here.
Many thanks for taking the time to look at this, and for acknowledging the issue and creating a new bug report - it's much appreciated.