Courtesy accidentals lost in transposition
Steps to reproduce bug
1. Open "courtesy accidentals.mscz". Notice courtesy accidental in measure 2
2. Press "Concert Pitch"
Expected behavior: Courtesy accidental should remain in place
Actual behavior: Courtesy accidental is lost
Discussion: Marked as critical since it represents loss of data.
MuseScore version: r. 3106 nightly build
(Operating System: Windows 7)
first reported by ph: http://musescore.org/en/node/5898
Attachment | Size |
---|---|
courtesy accidentals.mscz | 1.54 KB |
Comments
I consider this to be the #1 most critical bug I have encountered in version 1.0; perhaps the only bug that in itself demands the release of a bug fix release. There are many hours of work waiting to be lost forever on account of this. Note that on the trunk, the behavior is different, but still sometimes wrong. The courtesy accidental remains, but doesn't change as it from from sharp or flat to natural or vice versa. For example, a courtesy E natural in concert pitch should become an F# when transposed for Bb trumpet/clarinet/saxophone, but on trunk it displays as F natural.
Until it is fixed, there is a workaround. Instead of simply adding a courtesy natural to the note, drag or double click a natural sign from the Symbols palette. If entered as a symbol, the natural sign will remain whether in concert pitch or not.
(By the way, the way to access the complete list of available Symbols is to press the letter Z on your keyboard. The regular palette Symbols menu only displays a few of them.)
I used the example of a natural sign, but the process of course also works for any accidental.
FYI, items in the Symbols palette have no contextual meaning to MuseScore, it is just a symbol placed on the score. A courtesy accidental from the symbols palette will not transpose as described in comment #1 above, but it will not go away during transposition either. Also the symbols palette items have no impact on playback (of course this does not matter for courtesy accidentals since playback isn't affected). It is a short-term workaround, but be aware that after this critical bug is fixed you would still have accidentals from the symbols palette in your score that don't behave like accidentals.
Another problem with the workaround is that it would always display the courtesy natural as a natural (assuming it was entered as a natural), even though the correct accidental for the new key might be a sharp or flat. For example, a courtesy E natural entered in concert key but then transposed for trumpet needs to come out as F#, not F natural. This is the same problem I described above as being present in the in the trunk (as of the last time I checked - build 4003).
For now, I'm just being careful not to enter courtesy accidentals until I'm at the stage where I'm done with any need to toggle concert pitch on or off - basically, when I'm done with note entry.
Of course, you are right, assuming you later made changes to the piece and especially if you transposed it. Yes, this is only a temporary workaround and would not always work if you made substantial changes to the music later. I believe I used the term "workaround" when I originally proposed it. This is best done a penultimate step prior to finalization and printing.
“FYI, items in the Symbols palette have no contextual meaning to MuseScore, it is just a symbol placed on the score.”
Actually, I was well aware of that. But that is its strength in this context and the reason why I suggested it in the first place. It is therefore not affected by toggling between written and concert pitch. Your suggestion that you might make further major changes to the piece (including transposing it) was not a consideration earlier. I am sure that careful consideration would come with several other reasons why this solution is not "perfect" in all conceivable circumstances.
Recently, I was writing a piece where the courtesy accidentals were constantly disappearing. I was driven to distraction wondering why until I discovered the problem with toggling to and from concert pitch. This solution saved the piece and my sanity (at least temporarily).
Meanwhile, let us hope for a MuseScore revision.
Just to clarify, I'm not talking about transposing in the sense of actually modifying a thing. I'm simply talking about toggling display in concert pitch. This is not a major change; it's not a change at all. It's just changing how something is displayed - like zooming in, or scrolling. And unfortunately, the need the do this is the whole point. If I didn't need to toggle display of concert pitch periodically, I wouldn't *need* a workaround - I'd never encounter the bug in the first place. Regular courtesy accidentals work just fine as long as I'm not toggling display of concert pitch. But I do appreciate the suggestion.
I still think this is the #1 most critical bug to fix for a 1.1 release. It's the only way I know of to reliably lose hours of work in a single legitimate keystroke, and there is no real workaround - there is just no way to get courtesy accidentals to transpose. But since the symptoms differ between 1.0 and 2.0, and I imagine it might need to be fixed differently due to changes in the architecture, I've created a separate issue for this as it relates to 2.0:
http://musescore.org/en/node/10527
@Marc I read you several times with talking of number #X bug and it suggests you have a list. Could you make a post on the forum to let us know ?
Well, as I wrote above, this is actually the *only* bug in 1.0 I consider critical in itself. I haven't prioritized anything after that because nothing else strikes me as nearly so important. A 1.1 release that included a fix for this this and nothing else would be fine by me, although of course I'm sure others have bugs they'd consider high priority, and really, any of that large batch of bugs I submitted within a day or two of each other a couple of months ago could be worth consideration. I'll look over that, though, and make a post with my picks.
Would that be a valid fix ? If yes, can someone create a more extended sample with possible corner cases ? (A drummer is speaking ;) )
http://www.screenr.com/Ttw
I don't understand exactly what I'm seeing here, but at face value, whatever is going on, no, it doesn't appear to demonstrate a fix. Instead, it shows an even *worse* behavior - the behavior we see in 2.0. To wit, the courtesy accidental is not lost, but it is simply preserved unmodified, and in the case shown it should have changed, from a sharp (in the key of G) to a natural (in the key of C). So now we have a wrong note, which is much worse than a correct note that just happens to lack a courtesy accidental.
Let me be more specific. The example shows two accidentals. In the first (transposed) view, in the key of G, there is an F natural in the first bar that is an ordinary (not courtesy) accidental, and an F sharp in the second bar that is a courtesy accidental. The latter uses parentheses, which are not actually needed, but they do help identify which accidental is which in this case. After hitting the Concert Pitch button, the view changes to concert pitch - key of C. The first (ordinary) accidental is transposed correctly - F natural becomes B flat. But the second (courtesy / parenthesized) accidental is transposed *incorrectly*. The F sharp should have become B natural, not B sharp. This is *worse* than simply losing the courtesy accidental - it's actually notating the wrong pitch. This, unfortunately, is what 2.0 does too. The third view - after transposing the passage using Notes->Transpose - worked correctly, but I assume it too would have failed had the interval chosen been one that should have turned the courtesy sharp into a natural (like down a perfect fifth).
The behavior shown here is what I'd expect if accidentals were just dumb graphics (created with the symbol palette, for example), but accidentals - whether ordinary or courtesy - need to be treated according to musical meaning. The courtesy accidental in parenthesis in the first (transposed) view has the effect of confirming that the pitch is as specified in the key signature: F sharp. Similarly, the courtesy accidental in the second (concert pitch) view needs to have the effect of confirming that the pitch is as specified in the key signature: B natural.
The bottom line is that accidentals - both ordinary and courtesy - absolutely need to be key-center aware. Depending on the key and specific pitch involved, sometimes the accidental needed to *raise* a pitch is a sharp, sometimes it is a natural (if it was flat to begin with), and sometimes it is double sharp (if it was sharp to begin with). Similarly, sometimes the accidental needed to *lower* a pitch is a flat, sometimes it is a natural (if it was sharp to begin with), and sometimes it is a double flat (if it was flat to begin with). That is how ordinary accidentals work - they either raise or lower pitch. Courtesy accidentals don't *change* pitch; they simply *confirm* pitch. But it's still the case that sometimes the accidental needed to *confirm* the pitch is a natural (if it was a natural to begin with), sometimes it is a sharp (if it was a sharp to begin with), and sometimes it is a flat (if it was a flat to begin with). That is, the same logic applies to both ordinary and courtesy accidentals. A courtesy accidental is just an ordinary accidental that happens to not alter the pitch.
It was indeed a silly question. Thanks for the reminder. Still I would love to have a score to test with corner cases. (Fb, B#, double sharps etc...)
Here is the result I got so far : http://www.screenr.com/BJw
Looks good lasconic!
Yep, that seems to nail it. You've got some good tests right there already. I'll try to think of more, but I suspect you've nailed it.
BTW, as I'm sure you've all seen, II went ahead and posted a prioritized list of the things I'd like to see in a 1.1 release. It occurs to me that when I've made offhand references to such-and-such being my #X concern, I think these were mostly new features I'd like to see in 2.0 as opposed to outright bugs in 1.0. But just in case they could be done for 1.1, I went ahead and listed some in prioritization.
hopefully fixed in branch 1.X in r4287
I put this bug on fixed. For trunk see #10527: [trunk] transposition of courtesy accidental incorrect
Automatically closed -- issue fixed for 2 weeks with no activity.