Key change not respected when percussion clef involved.
I think this may be related to this issue, but I'm not positive. When a key change occurs while a part is an instrument in percussion clef (unpitched) (probably the tablature clefs too), the key change isn't respected when the instrument changes to a pitched instrument and changes to a pitched clef. If this isn't related to the previous issue, I'd be more than happy to create an issue for it. I've attached an example score that shows the problem.
As a workaround, you can Ctrl/Cmd-drag the key change onto the affected parts wherever it occurs.
Runtime Info
- OS: macOS 13.3
- Arch.: x86_64
- MuseScore version (64-bit): 4.0.2-230651546
- revision: dbe7c6d
Attachment | Size |
---|---|
KeySig Problem.mscz | 21.24 KB |
Comments
Interestingly enough, I'm finding that the workaround I gave isn't working in the actual score I'm working on. I'm investigating it a bit more currently.
In reply to Interestingly enough, I'm… by cawaltrip
It appears the workaround actually is working, but because the original instrument (the generic "Percussion" instrument) for that part was in percussion clef, the key signature isn't appearing anywhere. The key signature information is stored, because accidentals will be added where appropriate, and, if the part is exported to MusicXML, I see the key change at the correct measure in the export. That leads me to believe that this is also an artifact of the previously mentioned issue. I'd love to hear if @Marc Sabatella agrees with this.
I'm guessing the workaround for this would be to create a part that uses an instrument with a pitched clef and immediately add an instrument change to the unpitched instrument.
In reply to It appears the workaround… by cawaltrip
Does the staff type change help here?
https://musescore.org/en/handbook/4/staff-type-change
In reply to Does the staff type change… by Henk De Groot
Yep, that looks like it solves the problem of the key signature not appearing. The correct key signature still isn't propagating, but that's the known bug in the previous issue I mentioned. Thanks for the tip!