Transpose menu item transposes to the wrong key

• Jul 5, 2015 - 14:57

I'm attaching a score in the concert key of B. I'd like to transpose it to the concert key of Bb.
When I try this, I bring up the Notes->Transpose gui, select By-Key, Closes and select Bb/Gminor, and press OK.

Screen Shot 2015-07-05 at 15.50.52.png

Rather than transposing to Bb, it actually transposes to A.

There are several peculiar things I've noticed about this score. It has lots of transposing instruments, including Bb, F, and Eb as well as C instruments.
All the Bb instruments are written in the key of 7 sharps, the C instruments in 5 sharps, the F instrument in 6 sharps, and the Eb instrument in 4 flats. This is correct. But when I press the Concert Pitch button to see everything in the concert key of B, then everything appears in B except for the Eb instrument which appears in 7 flats = Cb. This is not really wrong as much as unexpected.

I'm not sure whether this anomaly is what is causing the strangeness in transposing.

Attachment Size
Screen Shot 2015-07-05 at 15.50.52.png 67.31 KB
Dallas.mscx 1.08 MB

Comments

Just did a fresh build (linux, 79a8fc8) and confirm that this still happens (Expected Bb, got A) with this score. Removing the Alto Sax made no difference to the transposition error. Transposing down by interval (Augmented Unison) works as expected. Using [Shift][F2] works fine.

I tried creating a new score with piano, Bb cornet, Horn in F and other instruments and Transpose worked fine on it.

Was there anything in particular about the way this score was created? Did you enter the Key Signature of B Major at creation, did you add individual Key Signatures, was it imported from a MIDI or other file?

One key to seeing what is going wrong is that when you first open the dialog, it has not correctly determiend that the actual key is B - it says C major. So when you ask it to transpose to Bb, it thinks that is a whole step lower, and hence you end up with A. Workaround, then, is to select the interval rather than the key.

The reason the dialog is confused about the original key is that MuseScore uses the top staff to decide what the key is, and the top staff in this case is actually a percussion staff, made invisible in Edit / Instruments. Percussion staves have no key signatures, which makes them appear as if they are C major.

I thought there was code to skip percussion staves when determining the original key, but apparently not. The code I was thinking of is for when you add a new instrument and we copy the original key signatures to the new staff: https://github.com/musescore/MuseScore/blob/79a8fc8e791e6456c5efd10f613…

We could use similar code here:

https://github.com/musescore/MuseScore/blob/79a8fc8e791e6456c5efd10f613…

Can you file a bug report in the issue tracker?

In reply to by Isaac Weiss

1] The OP was trying to resolve an issue so it doesn't really "count as" a duplicate post. Since we're not counting postings anyway and no deliberate breech of etiquette was intended, why worry?
2] The forum title of "Support and bug reports" does lead one to report Issues here even though deeper delving then goes on to suggest filing it in the Issue Tracker.
3] Anyone else could have filed an Issue whilst giving advice to the OP to file an Issue.
4] I have filed the Issue.

In reply to by underquark

Indeed, normally I would have, if the OP was a newbie to these forums. But in this case, Jim has been around the block a few times, and, if he wasn't familiar with the way it works, I thought I'd point him in the right direction and let him take care of it. Whatever; it's not a big deal either way.

EDIT: In fact, he is familiar with the way it works, as examples like #24628: Play always starts in the wrong place show. It wasn't more than a momentary error. The issue for this topic is #67836: Transposition of score by key gets incorrect interval if first stave is unpitched.

In reply to by underquark

FWIW, I like it when people post here first if they are not 100% positive something is a bug or are not sure if it has maybe been reported before or if maybe somehow the bug was a result of an import of an invalid file or work done in an experimental non-released build etc. It's good to get confirmation something is worth filing first when there is doubt. I also personally like it when the discoverer of a bug files it himself - somehow it helps give added weight to a bug in my mind when it comes from "outside" - even if Jim is hardly an "outsider" :-). So I often suggest they do so rather than doing it myself. Especially if pressed for time as I was this morning - and am now.

For the record, I am working on this, have it half fixed, but will come back to it tomorrow.

Do you still have an unanswered question? Please log in first to post your question.