Applying key change to a selection causes crash if transposing instrument is involved

• Jan 18, 2021 - 06:30
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

This bug causes a crash when a multi-measure key change is applied to a score with an instrument. Of the the half dozen instruments I've tried, they all reproduce this crash. NB, the only way I have found to not crash during a multimeasure key change, is to use 'treble clef' as the instrument. Once a 'treble clef' score is changed to an instrument, the crash happens.

Steps to reproduce:
1. Open a score with an instrument (eg flute, violin, etc. but not a 'treble clef' score)
2. Select a group of measures
3. Apply key change

Expected behavior: key change applied to selected measures.
Actual behavior: crash

OS: Ubuntu 20.04.1 LTS, Arch.: x86_64, MuseScore version (64-bit): 3.6.0.487916429, revision: 1977cb3

Comments

• Jan 18, 2021 - 07:59
Status active ⇒ needs info
Frequency ⇒ Once

What is a "multi measure key change"?
Selecting some measures and applying a key change does appliy it to the 1st meaesure of the selection for me, just like it should, no crash

Please provide a sample score

Reply

• Jan 18, 2021 - 16:23

I've tried with a number of scores, no crash for me either. Definitely we need the specific score with the issue in order to investigate. My guess is it contains some hidden corruption, perhaps in a part.

Reply

• Jan 18, 2021 - 19:57

By multimeasure key change I mean selecting multiple measures within a piece and changing only those. i.e. a 24 bar piece in C major, where I select bars 8-16, go to the pallet and click D major. The result should be that bars 1-8 remain in C, bars 8-16 are in D, and bars 16-24 are still in C.

I've attached the primary score I have been having issues with. It was created in an older version, 3.42 I think, and then updated to 3.6. At some point there was a corruption issue in bar 1890, but I deleted a few measures around there and corrected it manually.

I have had this same crash with other scores, but after further investigation, it may be only when the "68 Duets.." is open in another tab. If I start a fresh launch of Musescore without the "68 Duets.." score and open another score I don't seem to get the crash, but If I have the "68 Duets.." score open in another tab, then I do get the crash, even in the new score.

It should also be noted that Musescore runs extremely slowly with this score open. I tried exporting to mxl then re-importing, but the issue persists.

68_Duets_for_Two_Cornets_v4.mscz

Reply

• Jan 18, 2021 - 20:11

Do you perhaps have non-default soundfonts installed? That could be an issue. Anyhow, I tried loading your score here and doing a variety of random things with key signature but couldn't reproduce a problem. Please be as specific as possible. If this is meant to be open in a different tab than the score you re actually editing we need the score you are actually editing, and we need to know exactly which measures you are selecting, how you are applying the key change, etc.

Reply

• Jan 18, 2021 - 20:31

I don't think I have any custom soundfonts installed. I also just reverted to factory settings, but still have the issue. The attached score is the one I'm editing.

To create crash:
1. Open score
2. Navigate to score tab (68_Duets...) (as opposed to Part: Bb Trumpet)
3. using shift and click select bars 1-9 (top line) of top voice.
4. While bars 1-9 are highlighted in blue, go to palette, open key signature, and click D major

This results in a crash.

Thanks for your help with this.

Reply

• Jan 18, 2021 - 23:58
Title Multi-measure key change causes crash ⇒ Applying key change to a selection causes crash if transposing instrument is involved
Status needs info ⇒ active

Aha, that finally resulted in a crash! The triggers seem to be, the score has to not be in concert pitch mode, and the selected staff (or top staff of the selection, anyhow) has to be for a transposing instrument.

Reply

• Jan 19, 2021 - 02:15
Workaround No ⇒ Yes

Yes, and also, simply adding the key changes at both ends separately. It's actually a pretty little-known and little-used feature of applying the key change to a selection like this, which is how the bug escaped detection until now (it was probably introduced at 3.5 along with the new option to control whether or not transposing instruments should prefer flats or sharps).

Reply

Fix version
3.6.1