Adding transposing instrument to a score in C yields no key signature

• Aug 30, 2014 - 18:13
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Ubuntu Studio 14.04, GIT commit: 244f40d

1) new score for flute & oboe, key of C
2) after creating score, add Bb clarinet

Result: no key signature for the clarinet. This remains the case after pressing Concert Pitch button.

Workaround: explicitly drag a C major key signature to the score; this will give the clarinet a D major key signature while concert pitch is turned off, C major when turned on, just as it should.


Comments

Status (old) active patch (code needs review)

https://github.com/musescore/MuseScore/pull/1247

Some decisions need to be made about best way to handle this; see my comments in the PR.

The basic issue is that if a score is in C, the key signature is not actually fully created. It's either not created at all, or created in the segment list but not added to the staves' key maps. And its the missing entries in the top staff's key map that is the issue. The new instrument is copying the key signatures from the top staff, transposing them as it goes, but there is nothing there for the initial signature, hence nothing to transpose.

@Marc, when I explicly try to change the key of the soprano saxopone (a Bb instrument) to D (2 sharps), what happens visibly is that it changes to E (4 sharps), leading me to believe that it was already in D but just didn't show the signature in the rendering.
Does your proposed fix address this issue, or are they really two different issues?

See my comment in the issue you posted. What you describe is correct beavhior and not a bug at all. Dropping a key signature affects the whole score, not just the staff you are thinking about when adding it. When you add a key signature to a score, MuseScore takes it be the *concert* key signature, since it is going to add to all staves at once. So adding D major means adding E major for soprano saxophone, B major for alto saxophone, A major for horn, and D major for flute etc.

There has been a request for MuseScore to automatically detect which staff your mouse pointer happens to be closest to at the moment you drop the key signature and reiniterpreting the key signature relative to that. So if you drag a D major key signature to your score and happen to release while your mouse pointer is closer to the soprano saxophone staff than to the flute staff, it will assume you mean D major *for the soprano saxophone* and will transpose for everyone else as appropriate, yielding D major for soprano sax, A major for alto, G major for horn, and C major for flute etc. Or, if your mouse pointer happens to be closer to the alto sax at the moment when you release, you would end up with G major for soprano, D major for alto, C major for horn, and F major for flute etc.

While there is a certain logic to this, I think it would be counterintuitvie in general for any change that affects the whole score to depend so heavily on where your mouse pointer happens to be at the moment you release. It will make the behavior seem unpredictable to people who aren't necessarily focused on exactly where they release the mouse. After all, you don't have be that careful when releasing segnos, coda, time signatures, voltas, etc - they all affect the entire score the same way regardless of the precise vertical position of the mouse pointer at the moment of release.

On the other hand, until very recently, dragging a key signature to the score highlighted the entire column of measures across all staves - which was accurate since the action affects all staves - but now it already detects which staff you are closest to only highlights that staff. I think that's a bug, though. Since the action affects all staves, it should highlight all staves. This is how it works with time signatures.

The "problem" of having to focus on where the mouse button will be released isn't an issue. After all, for accidentals, graces notes, fingerings and others, people have to be even more precise and point directly on a note! For a Key change, we'd only need to drop it somewhere on the instrument staff...

@Marc, yes that explanation makes sense indeed. However my $0.02 worth is that if I'm composing for non-C instruments. For example a saxophone quintet will have all Bb and Eb instruments. If what you are saying is correct, then to change the Bb instrument to A, and the Eb instrument to E at measure say 56, then I'd have to actually drag the G key signature onto measure 56. That sounds really counter intuative to me, because it might well be that none of the instruments in the system is a C instrument.

In any case I understand that this effect is by design and not a bug.

Jim

Yes, but the use model is completely different between key signatures and grace notes.

When we add a grace note (which, BTW, is normally done by double clicking - drag & drop is not required), we know we are adding to one staff only - to one *note* only. So with grace notes, even if for whatever reason you do choose to use drag & drag, you know perfectly well that when releasing, you have pay attention to exactly where you release, and the highlight correctly reflects this - it shows exactly the one and only note you are actually dropping onto. You start off thinking "I want to add a grace note to the "C" in the third measure of the flute part", and everything about how you perform the operation reflects that mindset - you are completely aware of which note on which staff you are affecting, and your actions are directly determined by this.

Whereas signatures do *not* affect just one note or even one staff - they affect all staves in the score. In this sense, it is nothing like a grace note but everything like time signatures, segnos, and other markings. And none of those marking cares about the vertical position at which you release, so people would be in the habit of not *thinking* about vertical position for such items. After all, when adding a grace note, you have to be *thinking* about exactly what note you are adding to. When adding a time signature to a score, you don't start off by thinking about any one staff in particular at all - you know full well you are making a global change that will affect the the entire score. You don't think, "I am adding a 3/4 time signature to the "C" in in the third measure in the flute part"; you think "I am adding a 3/4 time signature to *the score* at measure three". And therefore, when dragging and dropping (the only way of adding a time signature), you know you don't have to drop carefully on any single note - you drop anywhere in the vicinity of measure 3, and the whole column highlights to let you know it's OK to drop, which in fact it is. And no matter where your mouse pointer is when releasing, if measure three is highlighted, measure three is where that time signature is placed. You don't need to think about vertical position at point of release - the highlighting tells you everything you need to know.

And so it should be with key signatures. When writing music for ensembles, one is normally most aware of the key of the piece as a whole. The fact that some instruments may happen to be transposing instruments is not normally very present in one's head - that's a mundane detail MuseScore takes care of for you. One simply thinks, "I want to change the key of *the piece as a whole* to D", and you expect MuseScore to figure out the transpositions for you. And because you are normally thinking about the key of the piece as a whole and not necessarily about how it will affect any one instrument, it makes sense most of the time that dragging a key signature works exactly like time signature, because the *mind set of the user* is the same in both cases (they are thinking about the *score*, not any one particular note on any one particular staff).

Now, I realize that there are exceptions - time when for whatever reason one is so wrapped up in dealing with one staff that one temporarily forgets there even *are* other instruments, or that they might be in different keys. And in those specific situations, you might be fooled into thkining in terms of adding a key signature also being primarily about the staff you have just been thinking about, rather than being a global operation like adding time signature changes. i do get that, and indeed, as I've said before, I've experienced this myself. But the moment one steps back and considers the bigger bigger picture - people working on the score as a whole and not necessarily being focused in their mind on just one part - you see how surprising it would be if the same drag & drop operation produced different results depending on the vertical position of your mouse at the moment of release. That makes sense for operations that truly are note-specific or even measure/staff-specific. but key signatures, like time signatures and voltas, are global, and that's how most people will thinking about them most of the time.

So we surprise the few people who for whatever reason are focused on only one staff of the score at any particular moment, but it's the right answer for everyone else - including people who might *sometimes* be focused on one staff, but *other* times be thinking more globally.

The thing is, people rarely compose while not in concert pitch mode - so adding of key signatures is going to be very rare except in concert pitch mode. And MuseScore can't be in the business of guessing whether you are thinking about concert pitch or an individual staff. Nor should it's behavior depend on whether where score happens to be for saxophones *only* or whether you've also added, say, a piano part. Consistency really worth something.

That said, it *is* a bug to me that currently the entire measure column doesn't highlight when dragigng a key signature without "Ctrl".

Status (old) patch (code needs review) active

So despite all I've said explaining why the current method really does makes sense, I do still understand the initial surprise one might experience if really is just focusing on one staff when adding a key signature. And the fact that only one staff now highlights when dragging makes it seem all the more surprising.

Since, as I said, most actual composition takes place in concert pitch mode, I might actually be coming back to my original view, which I was talked out of before but am being talked back into now :-)

As I see it, something needs to change. Either we change the highlighting to be clear that the key signature really is being added to all staves (which hopefully serves as a better clue that you need to be thinking globally), or we change the behavior so that if concert pitch is *off*, we calculate the key signature relative to the staff being added, so dropping "G" on a soprano sax staff adds "F" to flute etc.

In any case, I'm going to be re-submitting a PR for the actual bug that started this thread (behavior on adding an instrument to a score in "C" - not about dragging key signatures at all) and will want to be able to close this issue when that fix is made. So maybe rather than continue to discuss the key signature drag&drop behavior here, someone could open a new issue for that? Or it might be better to discuss further on forum first.

If someone composes for saxophone with only one staff, the most intuitive (and which doesn't need explanation by other users) is to change the staff according to what key is drop on it.

Status (old) active patch (ready to commit)

Yet another PR to fix the issue of adding transposing instruments to a score whose top non-percussion staff starts off in "C" - this one a very minimal change that should be safe to merge independently of how we decide on some of the more fundamental questions about representation of "C" key signatures:

https://github.com/musescore/MuseScore/pull/1306