[MU4 Issue] couple issues when changing instrument between pitched and unpitched percussion

[sammik]

Describe the bug

1. If instrument changes to unpitched, key signature remains in staff (present in following systems) already reported as #14702

2. If instrument changes to unpitched, transposing score transposes also this unpitched instrument

https://user-images.githubusercontent.com/1646034/203726770-a179081c-477d-4cc2-995a-af78418adca8.mp4

3. If instrument changes to pitched, clef and key signature is missing (also in next system)

If clef is added manualy, it is shown as expected. 3b) But if key signature is added manualy, accidentals are changed, as if keysig were there, but it is not present, nor in next system.

https://user-images.githubusercontent.com/1646034/203727021-6bee22e6-c799-4918-a069-e776912f39ca.mp4

4. If Key signature is changed in score, and unpiched instrument is changed to pitched in next bars, staff misses this key change

https://user-images.githubusercontent.com/1646034/203727048-d502d9c3-fb91-4d8b-8ae7-9efc0ac2eee3.mp4

Platform information

• OS: [reported on Linux]

[GabeS573]

Here's a quick summary of the expected behavior for these issues:

• Switching from pitched to unpitched percussion should create a courtesy neutral clef and should stop showing key signatures.
• Switching from unpitched to pitched percussion should always generate the correct courtesy clef, and should also generate the same key signature that is being used in the other instruments at that point in the score.
• Pitched percussion after an instrument change should still be able to show key signatures.

[fredg999]

For bugs 1 and 3, see my comment on #14702 regarding the key signature issues. The clef issues seem to be fixed already.

I was able to reproduce bug 2. I'll add that the bug still occurs even if a staff type change is added before trying to transpose.

I was able to reproduce bug 4. I'll add that the bug also occurs if you add the instrument change first and then add a key signature change prior to that bar. I'm not sure how MuseScore distinguishes global and local key signatures internally, but if there's a way to retrieve the global key signature, it should probably do that.

[sammik]

working on it Ill include this into complex instrument chagne fixes PR

[zacjansheski]

Adding here: Switching from a transposing instrument to a percussion instrument adds a new key signature (presumably to get it back in "concert pitch"). This is a regression from ms3

[its-not-nice]

@sammik Are you still looking at this? If there's a safe enough fix for any of the remaining issues we may be able to include them in 4.2; otherwise this will be bumped.

In the current 4.2 nightly build (MuseScore version (64-bit): 4.2.0-233270304, revision: github-musescore-musescore-5384a15), points 2, 3 and 4 seem to still be actual, as does Zac's point from the previous comment.

[sammik]

@oktophonie Sorry, I am out of my computer for a while. But if I remember correctly, it was already fixed in my local build, but it was part of quite bigger PR, and I dont remember, if it would be possible / easy to separate just this issue. I think, Zacs point was fixed already there too (and many other things), but if I remember correctly, I stuck on two things:

1. (no)design of #19107
2. problems with staffTypeChange

• it should be part of instrumentChange, but staffTypeChange has parent Measure and other elements has parent Segment (I forced instrumentChange to begining of measure, but in fact, it doesnt fix all issues: if user changes Time Signature, instrument change can became in the middle of new measure anyway; possible solution could be: a) change staffTypeChange to have segment as parent, or b) automagically split measure, if instrument change appears in the middle of measure
• may be better to merge staffTypeChange issues fixes first (#21260 #19089 #19035 #18810 /last one is potentialy fixed by #19086/ and may be others I dont remember)

[sammik]

I ll have my computer back after weekend, I hope.

[wizofaus]

I'm happy to look at this providing there's agreement over what the correct behaviour should be.

[zacjansheski]

@sammik @oktophonie I know this all has gotten a little stale, but a summary of the current state of this would be very helpful.

at the risk of oversimplifying this, I believe this should be the behavior:

1. Changing from non-pitched percussion to tonal instrument should always show a clef and key sig at the instrument change.
2. Changing from a pitched instrument to a non-pitched percussion instrument should not show a key sig, only percussion clef. Following key signature changes should not appear on the non-pitched staff
3. Key signature changes should appear in tonal instruments, including if a non-pitched percussion instrument changes to a pitched instrument prior to the key signature change.
4. Switching from transposing/concert score/parts should only change displayed relevant pitches and key sigs for transposing instruments, not the "rules" described above.
5. If the user still wants to alter something relevant here, they can do so with visible/invisible and local key sigs.

Please let me know if I missed something or if I'm off-base on something.

[sammik]

@zacjansheski it looks correct to me.

curent state is same as commented above - my solution was based on connecting InstrumentChange always with key signature, clef and stafftype

and there are still relevant issues with stafftypeChange (named above, and apart them also at least one other - changing measure duration casuse incorrect positions of all following staffTypeChanges)

I think, fixing staffTypeChange issues is needed first to move on. Once it will be fixed, I can rebase and tidy up work, I did once upon a time: #23053 (Or someone else working on theese things may find some points there may be.

[wizofaus]

See also https://github.com/musescore/MuseScore/issues/22645 where I mentioned the same issue and provided an example showing the key signature being revealed after changing clef without affecting spacing in other parts.

[bkunda]

It seems to me that work on this issue is still ongoing. @sammik @zacjansheski @oktophonie does anyone have any information about the status of work on this? If it looks like no further activity can be made on this in the next 2 weeks, then we'll need to move it to the backlog.

[sammik]

It seems to me that work on this issue is still ongoing. @sammik @zacjansheski @oktophonie does anyone have any information about the status of work on this? If it looks like no further activity can be made on this in the next 2 weeks, then we'll need to move it to the backlog.

@bkunda from my POV staffTypeChange needs to be fixed first, and it doesnt look like trivial fix. #21260 is backlog already, so it seems this needs to be too.