Request method to specify that key signature being added is already transposed

• Jul 26, 2014 - 19:43
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

When creating or changing the key signature of a Baritone Saxophone, the key signature is not the one I selected.

Steps to reproduce :
1. Create a new score with a Baritone saxohpone
2. Select D major for the key
3. Click finish.
4. The key shown in the score is B major.

If I switch to Concert pitch, the key is the one I chose. So there's a bug between the two pitch mode when setting a key signature to an instrument. Same happens when drag-dropping a different key sig.


Comments

Unless I am misunderstanding you, this is exactly how it is supposed to work. Baritone saxophone is an Eb transposing instrument, meaning it displays three fewer flats / more sharps than the actual concert key. The key signature selection is always selecting the concert key, not the written key - and you'll see why this makes sense as soon as you consider scores for several instruments of different transpositions. They would all have different keys, but the same concert key. So the key selector - which applies to all instruments at once - must set the concert key because that is what the instruments all share.

Status (old) by design active

Marc, I play in marching band. I know what concert key is! Yes, when we create a score, all instruments have the same concert pitch, but when I chose a key in the palette, this is definitely a bug.

If I'm in the instrument pitch mode, I'm expecting that the key signature that will be drawn in the score to be the one I choose from the palette! I have partitions printed partition in front of me that I just want to reproduce on MuseScore. I don't think it a good idea to force the user to try to figurer out which is the concert key. If I chose a specific key signature from the palette, that's because this is the one I need for the instrument partition I transcribing. Otherwise, I'd go in the Concert pitch mode to chose the key signature.

Steps to reproduce :
1. Create a score with only Baritone saxophone.
2. Not in concert pitch mode, drag a different key signature from the palette and drop it on the staff.
3. MuseScore writes a different key signature than the one chosen.

Expected result : draw the key signature that has been chosen in the palette.

MuseScore should take into consideration the pitch mode we are in so the key signature drawn in the score is the one we chose from the palette.

Status (old) active by design

Again, this is exactly how it is intended to work. It's how it worked in 1.x, and it's how most other software (eg, Sibelius) works as well. If the behavior were changed, how would you handle the case of multiple instruments? If you create a score for flute and bari and select D for the key - whether on initial score creation or by dragging a key signature in later - do you really want them both to appear in the key of D written - which would be D concert for the flute but F for bari? That would be disastrous! And it would be counterintuitive for MuseScore to act differently depending in whether a score is for one instrument or several.

Believe me, I understand how this seems surprising at first. But when you think it through, I think you will find that having key signatures working at concert pitch is the only way that make sense. If it's too much trouble to figure that out when looking at a written pitch part, you could always lie about the instrument and choose a concert key one.

I will say that in the special case of adding a key signature later, it would be *possible* to have MuseScore calculate the concert key for the staff you are dragging to and apply that instead. And I too thought of that at one point. But I was talked out of it :-). Given that you have to think concert key no matter what during score creation, it would seem inconsistent to have it work differently later. And in any event, since drag & drop of keys doesn't actually care if you drop directly onto a staff or not, the behavior would seem almost random. That is, drag a D major key signature to the score, but a millimeter up or down is the different between it adding add D major concert or F major concert. That would be highly non-intuitive! Dragging D major to the score should do the same thing regardless of exactly what vertical position you drop it at.

No, I'm still not convinced. In Concert pitch, I totally agree that if dropping a D major on any staff, all staves must become D major.

But in instrument pitch mode, the expected behavior is : the staff on which I drop the D major becomes a D major; the other staves adjust accordingly to their transposition key. That would make it simple for the user and wouldn't confuse the user as to "Why is a different key being draw than the one I chose".

As for Finale or Sybelius, I'm not using those softwares. But I think MuseScore can do better! :)

Status (old) by design active

Yes, what you suggest is what I mentioned above, and indeed, it is what I meant when I said I once suggested something like this but was talked out of it (just as I am trying to do now) :-)

As I said above, this suggestion has issues in that dragging currently doesn't *care* at what vertical position you release. As you can see if you try it, the entire vertical column highlights, just as is the case for time signatures, barlines, segnos, and codas. This is an important visual cue that the action will affect all staves, but it also means you can easily drop *between* staves rather than having to drop precisely on one specific staff, and then what should it do? That admittedly could be fixed by changing the highlighting to make it more clear you are dropping on a specific staff.

Still, I am not at all convinced it is the right thing to do. I realize when you're working mostly with single-instrument parts for transposing instruments rather than full scores, it might seem a no-brainer that you'd add the key signature at written pitch, but really, working with individual parts in that way is definitely the exception rather than the rule. Most people dealing with transposing instruments will be dealing with full scores. And if I'm dealing with a full band score and I get the idea to add a key change, I am thinking concert pitch even if some subset of the instruments I am writing for happen to be transposing instruments and are displayed that way. I am thinking about the *music*, not the transposition. If I drag the concert key signature to the score, I don't want to have think that hard about which staff I drop the key signature onto ("better drop onto a trombone staff and not a trumpet staff"). I just want to change the key of the piece.

The point here is that there really are valid reasons why it works the way it does - it's not a "bug" - and compatibility with how other major programs work is not to be taken *too* lightly.

On the other hand, it *is* true that while the "create new score" wizard has always and should always work in concert key, in MuseScore 1.3, adding a key signature later did not. it also affected only the current staff, though, and it was fixing this major usability issue (needing to change key signatures for each staff one by one) that I think led to the current solution.

Anyhow, no doubt it would be possible to implement the behavior you suggest, just not sure it is how things should work by default. Perhaps as a special command, like Shift+drag to get this behavior.

I've re-opened this as a feature request because I *do* think the idea has merit. I just think that in the general case - working with a full score rather than individual parts - the current behavior is actually *more* intuitive.

Hum, with more experience, I still think it's not user friendly to drop a transposed key.

It's normal behavior for a user to expect that the key signature it drops on a specific staff will bring the staff to that key, adjusting other staff accordingly. Maybe it's not feasible in the current state of MuseScore, but that would be much more obvious. If we need to add a message to explain a different behavior than expected, maybe we should adapt MS...

I was working on a Clarinet Eb and a Trumpet Bb score, and changing trumpet key signature from C to A should require the user to do math calculations... It should be : pick the A key and drop it on the measure where you want it.

So this should be the feature request for this thread. Maybe I could start working on this feature and people could chose their favorite behavior in the preference dialog? I'm sure it wouldn't be that hard to implement.

I suspect it would be trivially simple, actually, aside from the issue I keep mentioning - it just isn't necessarily clear which staff's transposition to use unless you very carefully drag to one specific staff (iue, you drop one a specific key signature element, not on the measure as whole), or if there is only one staff.

So I might propose that it be implemented that way - when dropping onto a measure, check to see if there are multiple staves, and if there is only one, use that staff's transposition. But otherwise, there just isn't any rational way I can see for MuseScore guess whether you were intending to drop on the Eb clarinet or Bb trumpet staff in your example. And I don't *want* it to guess. I want *predictable*, *repeatable* results. Dragging a key signature to any given measure needs to do the same thing each and every time I repeat the experiment - it can't vary according to where I happened to release my mouse. That would be a terrible bug - unpredictable results are far worse than predictable results that are unexpected at first but easily understood. I could live with the inconsistency in behavior between how drag & drop would work for single-staff scores versus multi-staff scores or drop on measure versus drop on key signature, because again, I do get why one might at first epxect this behavior. But I do implore people to recognize this *would* indeed represent a pretty serious inconsistency in how MuseScore works - the eact same oepration doing different things depending on something that would be non-obvious to the user.

This is a very interesting debate with pros and cons on both sides. The solution therefore should aim to be the most flexible, the simplest and also the most intuitively obvious, and I suggest the following:-

1) Leave the current function exactly as it is now for Concert Pitch mode.
- The chosen Key Signature from the palette is applied to all instrument staves.
2) Change the function so that in non-Concert mode, where the staves for transposing instruments should have non-Concert key signatures,
a) only one stave can be changed at a time, made visually obvious by highlighting during drag, and
b) the key signature chosen from the palette is applied directly, i.e. the transposed key.

The above implementation would mean no surprises for any user applying key signature changes to a big score or a single part.

By the way, as it works today, by creating instrument parts for a score, and then changing key signature on one part only, that instrument stave will retain the different key signature when the full score is viewed in concert. Maybe an anomaly, but can easily be reset by re-applying the concert key signature to the whole score.