Systematic crash when changing the key signature
I just added an instrument to a Big Band score. The score is in C (no alteration) The instrument I added is a Baritone Saxophone, so the added staff should have had a three sharps signature like the original Baritone Saxophone. However, it came with no alteration. When I try to change the key signature for this staff, MuseScore systematically crashes.
Note that the staff is named "Bari Sax / Trb 4" because it is supposed to hold the same (transposed) notes as the Trb 4 staff, but the instrument is still Baritone Sax.
Also, before the first crash, I had already copied the Trb 4 staff into this new staff and formated the corresponding part (which doesn't exist in the uploaded file). When MuseScore asked whether I wanted to restore the session, I said yes and everything was there (without the new key signature, of course). When I tried again to change the key signature, it crashed again, and after restoring the session, the new part (which contained both the original and the new bari sax staves) had disappeared (which explains why they aren't in the uploaded file)
| Attachment | Size |
|---|---|
| 461_Wave_BuddyRich_LaBarbera.mscz | 153.66 KB |
Comments
There's something severly wrong, if you toggle concert pitch (on and back off) you end up with an entirely different key signature
In reply to There's something severly… by Jojo-Schmitz
It might be related to another problem. Initially, the score had the normal Big Band instrument arrangement with two Eb alto saxes and two Bb Tenor saxes. The first few measures of the alto and tenor staves, though, are played by flutes, so these staves start with an instrument change. This changed the first five staves to C (no transposition)
Changing back the first staves to Alto sax, not only reintroduce transposition for the first staff, but also for the second one. After this, adding a Baritone saxophone staff correctly uses the transposed key signature (three sharps.) It looks like the three Eb saxophone staves (two altos and one baritone) are more or less linked.
Reversing the first staff to flute then reverse the second one but not the new bariton. It might be a workaround, although it's a bit terrifying for the future in case there are further modifications to make to this score. (I am sure there will be some, most probably at the last minute !)
The problem seems to be related to the fact that adding an instrument change at the very beginning of the staff changes the staff instrument. In other words, instead of an alto sax staff starting with a change to flute and then reversing to alto sax, we get a flute staff later changing to alto sax.
In reply to It might be related to… by Pierre-Yves Saumont
I made the following experiment:
1) Create a new Big Band score in C
2) Start the first staff (alto sax 1) with an instrument change to flute. This (incorrectly) changes the staff to flute. Although it is incorrect, it might be useful in order not to start with a key signature change.
3) Add an additional Baritone staff. The staff added is missing the Eb transposition. This is clearly a bug. The instrument in the first staff should not influence the creation of another staff.
In reply to It might be related to… by Pierre-Yves Saumont
The less problematic workaround was to delete the instrument changes to flute, which reversed the staves to alto sax and tenor sax with the correct signature. Changing the staff instrument back to the original for the first staff automatically changed the three following but did not restore the correct signature.
The score is not in C, it has no key signature at all. But it was notated using "local" C major key signatures, apparently one at a time using Ctrl to prevent them from being transposed or linked normally. That's the first problem. It should have simply used the atonal/open key signature. Then key signatures won't transpose, but will be treated normally in other ways
As it is, MuseScore sees the C key signature on the top staff and assumes it is truly C, so that's why you get three sharps for the added bari.
To fix this, what you should be able to do is simply add the open/atonal key signature to the score normally - not as a "local" key for a single staff only using Ctrl, but just the usual method of selecting a measure on any staff and clicking the open/atonal key signature. Unfortunately, as notated, this results in a crash due to the corruption that is now present. If you delete the parts, then it works. I see you've already some formatting work, though, and you probably don't want to lose that. So you might experiment with deleting parts one at a time to see if you can avoid the crash without deleting them all.
It's pretty normal that the recovery after a crash won't show the last couple of minutes of edits, and after two successive crashes, things can get worse. Usually after a crash recovery it's best to save explicitly as soon as possible.
In reply to The score is not in C, it… by Marc Sabatella
Thanks for your analysis, but ow can you see that the score has no key signature? Do you mean that if one doesn't specifically select no alteration (which would mean unselecting the default C key/no alteration option), MuseScore doesn't use the C key? How can this be detected on the score? In other words, how is the atonal/open key signature shown? And is it the key signature by default? If this is the case, it might not be what most users expect. But they might of course be wrong to expect anything else than atonal/open key signature.
This said, this wasn't the main problem(s). The problems are (by order of decreasing severity):
1) MuseScore crashes when changing the signature of a staff
2) Changing the instrument for a staff causes the instrument for another staff to change automatically.
3) Using an instrument change at the beginning of the staff changes the instrument for the whole staff.
4) Reversing the change by a different means, such as selecting the correct instrument for the staff while wanting to keep the instrument change for the first measures creates a mess.
5) Creating a new score (Big Band) and selecting the no alteration option (C key) causes the exact same problems (this in case you were right that I might have unintentionally deselected the no alteration option, which is very unlikely, but possible). See the procedure above to reproduce the problem. Once an instrument change to flute is put in the first measure of the alto 1 staff, the instrument for the whole staff is changed to flute, and adding a baritone staff later adds a staff with no alteration instead of three sharps. On the other hand, changing the instrument for the whole Alto 1 staff to flute is OK and a later added bariton staff has the three sharps.
It happens that the workaround is pretty simple: do not start a staff with an instrument change. Do not create a big band score with an alto sax staff when the first few measures are to be played by the flute, but change the staff to flute, even if 90% of it is alto saxophone. And above all, if you change the whole staff instrument with an instrument change, do not reverse by using another means (trying to fix the problem by changing back the whole staff instrument creates the mess).
The question is not whether this is theoretically correct or not (as much as an application crashing might be correct) but whether this is what the user expects. It might be right to not do as the user expects if the user is wrong, but there should be at least a warning. In my opinion, it should be possible to change instruments in the first measure without changing it for the whole staff. But if not, a warning should be displayed when the user inserts an instrument change at the first measure. Although it would not be necessary if changing the whole staff instrument was the only consequence, it should say that introducing an instrument change at the first measure might totally corrupt the score and cause later crashes. Of course, another solution would be to fix these problems.
In reply to Thanks for your analysis,… by Pierre-Yves Saumont
I can see the score has no key signature by navigating to where the key signature should be. For example, click a clef at the start of a staff, press Alt+Right. Navigation goes straight to the time signature when it should show a key signature. No key signature at all would indicate the key of C major. If there were an open/atonal key signature there as there should be for a score like this, Alt+Right on the clef would take you to that key signature and the status line would report it as such even though there is nothing visible in the score.
So right now, the key signatures in your score are in an inconsistent and somewhat corrupt state, presumably as a result of the handstands you must have gone through to force the transposing instruments to have no key signature when they should have. And that corruption is what is causing the crash. It's a bug no doubt that any particular series of handstands can produce corruption like this, so if you're able to come up with the precise steps to reproduce these conditions from scratch (and thus see the same crash), that would definitely be something to report in the issue tracker. But meanwhile, deleting the parts and re-entering the key signature normally fixes the corruption, and with it, the crash.
I'm not understanding what you mean about 2) or 3), though - I thought we were talking about key signatures, not instrument changes? Anyhow, any other oddities you are seeing here could simply be a result of the same corruption. If you continue to see the problems after fixing the underlying problem here, best to start a new thread as it would presumably be a separate unrelated problem.
In reply to Thanks for your analysis,… by Pierre-Yves Saumont
BTW, I don't know what you mean about "no alteration option". But to be clear: the key of C and the open/atonal key signature are two different things. Key of C means an actual key is present, and transposing instruments will honor it and thus show transposed key signatures. Open/atonal key means the is no actual key, and thus no key signature will be shown even when transposing. To select the open/atonal key signature, you need to do so manually, by clicking it (shows as a greyed-out "X").
In reply to BTW, I don't know what you… by Marc Sabatella
By "no alteration option", I mean that when creating a Big Band score, we are presented a choice of key signatures, and the preselected option is no alteration. I didn't change this default option. I didn't remove the key signature. I never saw anything looking like a greyed-out "X"). The only thing I did was to place an instrument change to Flute in the first measure of the Alto Sax 1 staff which resulted in the fact that when I added a second Baritone staff, it came with no alterations, which seems to indicate a key of C. Trying to fix this resulted in the corrupted score.
Whatever the theory about which key this score should be in (I consider it should be in C because this is what I need), there are several bugs involved:
1) Inserting an instrument change shouldn't change the whole staff instrument. It should stay an Alto Sax staff with a temporary instrument change to Flute even if this change occurs in the first measure.
2) This shouldn't interfere with the way the new baritone staff is added.
3) In any case, MuseScore shouldn't crash.
In reply to By "no alteration option", I… by Pierre-Yves Saumont
The default option in the key signature window is not "no alteration", it is "C major / A minor". This is, as I have explained, different from "Open/Atonal". Selecting the key of C major or A minor means you are telling MuseScore that the music is actually in that key, and that transposing instruments should use the transposed equivalent.
So it is completely normal that for a piece in the key of C major or A minor, a baritone saxophone part should have three sharps, because that is the correct transposition for baritone saxophone. If the piece is not actually in the key of C major but in fact has no fixed key at all, don't choose the key of C - choose the open/atonal option. Bottom line - since you chose C major / A minor and did not choose Open/Atonal, it is absolutely correct that the baritone saxophone received three sharps. This has nothing to do with any instrument changes you added anywhere, it is just how transposition works. A piece in the key of C major requires three sharps for baritone saxophone, period.
But yes, as observed, there is a bug in that changing key signature produces a crash. As I have observed, this appears to be due to a corruption that has occurred in the score, and other signs of the corruption can be seen by toggling the concert pitch button on and off. Since that corruption is most likely the root cause of the crash, what we really need to know is how to reproduce this particular corruption. So if you can reproduce this from scratch, please attach an uncorrupted score and the precise steps that lead to the corruption. Then we can investigate further.
I still don't understand what you mean about instrument changes, unfortunately. An instrument change is intended to change everything from that point forward, until the next instrument change. Adding to the first measure is indeed basically the same as changing the instrument itself. In what way would you expect it to be different?
In reply to The default option in the… by Marc Sabatella
I guess you didn't have the time to fully read my comments. When selecting a key for a Big Band score, you have to select a key signature by clicking on the proposed signature. There is no indication of the name of the proposed keys. Only images of the proposed signature. All are short staves with a number of flats or sharps. The default option is a short staff with no alteration. I am perfectly aware that this means the key of C, which is what I needed. Until now, there is no problem.
The created score has all the instrument staves with the correct keys due to the correct transposition. After thirty years of making scores for a Big Band, I even know that the Baritone sax, like the Alto saxes, is in Eb, so the corresponding staff has three sharps. Again no problem.
As you may know, saxophone players often also play the flute, which is in C, and don't need transposition. The score starts with seventeen measures of flute for the two altos and two tenors. So I inserted an instrument change in the first measure of the Alto 1, Alto 2, Tenor 1, and tenor 2 staves. I guess this is supposed to place a key change where the instrument changes, which is a C key (no alteration). But as it is in the first measure, it makes sense to not insert a key change but replace the existing key signature, which is what MuseScore does. Still no (apparent) problem.
But if you look at the staff properties, you realize that MuseScore has changed the instrument for the staves to flute. So, they are no longer saxophone staves with an instrument change to flute, but flute staves that will need a later (at measure 18) change to saxophone (either alto or tenor). This might or might not be a problem, but the staves are now labeled "Flute" instead of Alto 1, Alto 2, Tenor 1, and Tenor 2. Of course, changing the names back to the original names is easy. But changing the instrument staves back to saxophone is probably much more of a problem.
So, we have four staves that were originally using saxophones and are now using flutes. One particularity of this score is that it needs a second baritone staff. Lets' add it. Surprise! it comes without the key signature (no sharps)! This is clearly a bug since the overall key of the score has not changed and the Baritone transposition should be effective.
Sorting this mess is easy... once you have made all the needed experiments. But this is what resulted in the corrupted score. At one point, trying to insert the correct signature to the new baritone staff crashes MuseScore. This is not the only problem. Changing the key for the Alto 1 staff also change it for the Alto 2, but not for the rest of the score.
As I said, it is easy to reproduce. Create a Big Band score in C, insert an instrument change to Flute on the first alto staff, then add a baritone staff. It comes without a signature. I let you decide if it means C or Open/Atonal. From my point of view, it means A major with three missing sharps.
In reply to I guess you didn't have the… by Pierre-Yves Saumont
I did read, but I didn't necessarily fully understand, because you were using terminology ("no alteration") that didn't make sense to me. So I couldn't tell at first which key you wanted to use. The name of the key appears when you hover over it. I've explained the difference between C major and open/atonal, so hopefully it's clear now. Your piece is in C, so it's correct you used the C major key signature. And now that I understand your intent better, I can see better what you mean about which bar is the original and which is the new one and what the expected result was given the key.
That's part of why we always recommend posting a score in the state before the problem occurs, and then give us precise steps reproduce the problem. but yes, now with the confusion about the original key cleared up, the rest is a little clearer too.
So yes, I can confirm that the same corruption that causes the crash appear to also cause a problem in adding the new staff - given your intended key of C, it should have had three sharps. The question remains, how did the score get into this corrupted state. So again, what we really need are precise steps to reproduce the problem starting from a non-corrupted score.
BTW, Staff/Part Properties does indeed always show the current instrument - by design, so you can examine and change those properties (like to customize the staff name or transposition or range). So if you have an instrument change to flute - whether at the beginning of the score or anywhere else - and you invoke Staff/Part Properties by right-clicking in a passage that is actually played by flute, Staff/Part Properties will show you those properties, as it should.
EDIT: OK, this time I did fail to read that there are finally steps to reproduce, so thank you!
In reply to I did read, but I didn't… by Marc Sabatella
Here are some steps to reproduce some related problems with instrument changes:
1) Create a score, such as Big Band.
2) Generate parts for all instruments
3) Place various changes of key signatures in the score
4) Place instrument changes a some places
The changes of key signatures inserted in the score are reflected in the parts. The changes of key signature corresponding to instrument changes are not. See for example measure 17 of the Alto sax 1 staff on the score, which shows a switch to 4 sharps when the flute is replaced with the alto saxophone. On the corresponding part, the switch is incorrectly displayed as 1 sharp instead of 4.
The workaround is to place all instrument changes and key changes before generating parts. In case you wonder why I would generate parts for an empty score, it is because when copying from a paper score, it's easier to work with the line and page breaks in place.
I guess the previous corrupted score was due to various attempts at solving the problem by inserting the missing changes of key signatures.