Changes to staff transposition (and other properties) not reflected in linked parts

• May 28, 2015 - 21:04
Reported version
P1 - High
S3 - Major

Ubuntu 14.04, GIT commit: 9341f4e

1) new score, flute, key of F
2) add notes for an "F" scale
3) generate parts
4) staff properties
5) change instrument to Bb clarinet

Result: notes and key signature transpose in score, as they should. But view the part, and you'll see the notes is transposed but the key is not. Also, the octave is wrong for the "C". Press the "Concert Pitch" button while viewing the part and the notes display with the correct pitches, and the key signature remains "F".

If you check Staff Properties in the part, you'll see that it is still set to Flute, with no transposition. The notes transpose because the tpc's info was linked, but since there is no transposition data, the keys did not transpose. Not sure why the octave is off on the "C", but it seems a not surprising consequence of the tpc's being out of sync with the transposition info.

If you change other staff properties, like number of staff lines, you'll see these are not linked either.

At the very least, I think a change to transposition must affect linked parts. BTW, if you change the instrument in the part, everything works correctly - you don't get a second transposition.

I'm not sure if linking changes to staff transposition makes sense for linked staves of different staff types within a score, however - eg, a guitar staff & linked tab staff. I gather that there is some possible association between transposition and capo, but I don't know what's expected here.


Ran into this as well, fortunately saw the incorrect octave before handing off to players. :)

At the very least, I think a change to transposition must affect linked parts.


I'm not sure if linking changes to staff transposition makes sense for linked staves of different staff types within a score, however - eg, a guitar staff & linked tab staff.

I'm also aware of transposing guitars like Baritone guitar, but I have no idea what would be appropriate either.

The notes transpose because the tpc's info was linked, but since there is no transposition data, the keys did not transpose.

Chord Symbols will also not transpose in this situation.

I also wanted to add that some notes are transposed incorrectly.

In the attached score, I generated a part. In the part I changed staff properties to transpose whole step. Here is how the C scale looks

Part in Concert Pitch:

Part in Transposed Pitch:

Main score in Concert Pitch:

Main score in Transposed Pitch:

Hmm...I seem to have just saved that part score as this attachement, and didn't save the full score. Anyway, the attached part score still experiences incorrect transposition, as only the first note and all the chord symbols transpose correctly, but the rest of the notheads do not transpose when toggling concert pitch, for some reason.

Attachment Size
Untitled-Piano.mscz 3.45 KB

Just noting this is still an issue, and it also affect instrument change text - these don't affect playback in 2.0.3 nor do they affect transposition in 3.0. I could conceivably try to resolving this while I am working on incorporating my fix for #9352: Add ability to set transposition by range into 2.1, although I'd make a separate PR for this so it could go into 3.0 as well. But the reaosn I didn't try to fix it before is that I gathered there were some architectural things going on I was afraid to mess with. I'm commenting here mostly to remind myself to look into it further.

To me it's not about giving it a shot - I'm pretty sure there isn't much involved in the actual coding. It's about understanding at a more basic architectural level what is supposed to be happening. Which is to say, I would feel more comfortable if Werner were to weigh in. But also it's important to understand from from a user level perspective what the desired behavior is in all those particular use cases, and I don't have that information.

Good points...I won't worry about this until then.

As far as use case, if I can easily imagine an arranger who made and part for a particular instrument and carefully prepared the part score to look nice, later might decide to change that part's instrument to another instrument (either deemed more appropriate for that part or based on available musicians' instruments). I know I have done that a few times. Which is why for sure I think changes to staff transposition as well as other things like instrument and default clef (basically any staff or part property) need to be synced between linked staves of linked scores. But I'm not sure about linked staffs within the same particular a guitar part might have a tab staff linked to a traditional staff, in which case things like number of lines in staff wouldn't make sense to sync.

I agree 100% with Marc (maybe for the first time!) - this is not just a simple fix, anything you do to "improve" for some users may well have negative effects on others and you might end up shutting off the route to major improvements.

The case of transposed and non transposed parts is seems to be fairly well handled in 2.1 (apart from forced note stem directions being identical in transposed and untransposed parts) but different transpositions for the same part are another matter altogether.

I once thought I had a reason for changing an instrument, but this turned out fairly disastrous (as reported above). Normally, am not sure why you would change an instrument rather than adding an alternative.

I am involved in two different types of formation: a french fanfare (marching band) and a french harmonie (wind orchestra).

Multiple transposition is required for two distinct cases: fanfare big brass parts and uncertainty over the instruments that will be available.

For the low brass, there are baritone, saxhorn, euphonium and trombone players who are used to either concert pitch in bass clef or 14 semitone transposition (when will MuseScore allow transpositions in semitones?) in treble clef and "petite basse" players who are used to 2 semitone transpositions in bass clef (Yes, seriously, this is the standard from major marching band music publishers such as Robert Martin - these parts double as 14 semitone transpositions for BBb players!).

This requires
1) different clefs for different parts. Currently, clefs are not treated as layout elements and so are linked between parts.
2) parts for concert pitch plus two different transpositions.

The requirement for multiple transposition comes from the unfortunate reality that the instruments available vary in both time (absences) and space (with arrangements being passed from one formation to another).

Mid low brass and substitutes
Bb baritone -> Eb alto sax. In fanfare music, the baritone usually has the counter-melody. When your baritone players have died or no longer have any teeth, someone has to fill in.

Mid brass and substitutes
Eb alto (tenor) horn / F french horn
Bb flugelhorn -> F french horn, Eb alto sax

Eb alto sax -> Bb tenor sax. Normally our saxes just change instrument, but this can be awkward during a concert, so when the second alto has been pressed into playing the horn part, it is a good idea for one of the tenors to take the second alto without changing instrument.

Currently I deal with the problem by having a master score with duplicate instruments. This of course means that you have to redo all the little layout tweaks, such as avoiding collisions between dynamics and hairpins, for every part, over and over again, but Marc assures me that the solution is to improve the layout algorithms rather than copy the layout.

The biggest takeaway is that you must ensure that you have finalized the score BEFORE creating alternative instruments or transpositions and extracting parts. That way changing instruments is not an issue.

This is just my experience. There are probably many other reasons, but, fundamentally, in the real world of shrinking amateur formations (sad!) , transposition flexibility is essential. But, if you are going to be able to extract more than one part from a staff in the master score, much more independence (forced note stems, clefs, spelling, staff text ("con sord" for a sax!), glissandi and what else?), rather than less independence, is required.

Until then, duplicate your instruments in the master score.

Reproducibility Always
Reported version 3.3

Transposing the lead sheet changes Key in main sheet, but not in parts
It does correctly transpose the notes, as well as the chord symbols
I tried with and without select, by key and by interval.

This one is still a major issue. I had a playdown this week and came up with parts for saxes looking like that:
Here, a lot of notes are out of reach (Saxes don't go lower than Bb one line and a half under the staff).
Funny things if I toggle concert pitch I get this:
All the notes are perfect, it's just the keysig that is not. It should be showing what it was showing when it was in concert pitch.

Look at the score in concert pitch:
Sax is in F. In the parts, the sax is in D (when in concert pitch) and in B (when not in concert pitch).

Not ideal for a playdown. I had to head back home and come back an hour later with the new parts printed. Not very fun. Good thing I had the time. (Yes I know, I should've doubled checked before, but that's no excuse for MuseScore)

The score is clearly not transposed well. It did happen after an instrument change.
The score is attached.

Attachment Size
CorruptedParts.mscz 73.62 KB

In reply to by Marr11317

Workaround No Yes

Though the problem, according to Marc's post, is worse in 3.0, there is a workaround of sorts in 3.0. If you delete the part, then recreate the part, it is created correctly. The problem is that any special formatting done to the part, including changing the overall size and fine-tuning the positions of elements, is lost and has to be redone. This is better than nothing and, usually after transpositions, the parts have to have some of the special formatting reapplied anyway.

In reply to by Aaron Grosky

I sort of 'solved' the problem of changing the key of a part and still keep the formatting of that part, without deleting the part and creating it again by using the following method.

  1. Save the particular part as a new musescore file and then
  2. change the key or do any other changes needed in the new file created as required.

That is, let's say you have a composition with a title XXXX and you have 3 parts for flute, clarinet and piano respectively.

Let's say you want to change the clarinet part to be played by another instrument such as soprano saxophone. Then you click and go onto the clarinet part and save it using- Save as - and naming the new file eg. XXXX Soprano Saxophone. This way you have a new musescore sheet file with name XXXX Soprano Saxophone and in this file, you will have ONLY the clarinet part. The formatting etc you had in the clarinet part will still be there.

Now you can change key, partname and any other changes you need easily and you can print on paper or save the new part as pdf. You can choose to keep new file saved just in case you will need to do further adjustment soon or you can delete it, since after all, it's not too much of a hassle to do the process again.

This of course can be a 'solution' to be able to print the part or save it as a pdf without having to go through the process of editing and formatting again. In the original file- XXXX the clarient part will still be the same as originally created.