Transposing does not always affect the chord symbols as it should

• Jul 20, 2019 - 02:38

Hello, friends.

I have been using MuseScore for about one year now, and I am now on 2.3.2 on Vista. I am convinced that there is a bug in this version, and perhaps in previous versions, and perhaps even in version 3, in which the chord symbols do not get adjusted when transposing. I have seen other users report the issue, but no one ever thought of the possibility that this was simply an inherent bug related to the maneuver of ordinary automatic transposing.

It has happened to me many times with many different songs from all different sources, but never consistently, and certainly not usually, so my only conclusion is that it is simply a bug.

Yes, of course, I have the option selected in the "transpose" dialog box, to "transpose chord symbols." That was an obvious precaution.

Previously I have corrected the bug by simply restarting the program, and sometimes I have corrected it by copying and pasting staves, or changing the instrumentation temporarily,and then back to the original instrumentation, or by displaying the score in concert key, and then in the instrument key. Today I am faced with a case in which none of this seems to help.

To suggest that I upgrade to version 3 is not the point really, unless someone can affirm that this bug was previously identified and addressed specifically when developing the new version. I am stuck with 32-bit Vista, and there is no way for me to upgrade to v.3 on this particular OS.

Anyway, I am attaching the score in question, in case anyone has a solution for version 2.3.2, or even a nice work-around. I'll be grateful.

Thank you for your help.

Attachment Size
Run To You v.2.mscz 29.22 KB


You have no chord symbols in the score. You have staff text that looks like chord symbols. For chord symbols to transpose, they must be entered as chord symbols using ctrl+k.

In reply to by mike320

Wow. What a keen eye you have, Mike!. Thank you so much.

As I mentioned, this was the only score that I could not eventually correct myself, and I could not figure out why. I had acquired this score from the Wikifonia collection of years ago, so someone else had typed in the chord symbols long ago. Since they looked exactly the same as the symbols on any other score, I never dreamed that there was an issue regarding the type of text itself.

So, I stand corrected; this was by no means a case of the bug that I mentioned (although that bug does indeed exist where chord text is typed in correctly).

Thank you, thank you, thank you, Mike.

In reply to by ErikJon

Oh, so now I understand your previous post, also. You were telling me from the start, not that no chord symbols appeared, but that I had the wrong type of text for those chord symbols; I had thought that you were telling me that no chord symbols appeared in the sample that you had downloaded. Sorry for that misunderstanding, too.

In reply to by ErikJon

There is no bug that I'm aware of concerning chord symbols transposing. If there is, it needs to be understood so it can be fixed. Could you post an example of a score where the chord symbols do not properly transpose?

As far as the keen eye, I've learned a thing or two in the last few years hanging around this forum. Every problem I've ever seen with a chord not transposing was because it wasn't a chord or it was entered improperly.

To transpose correctly, chord symbols need to be recognized by MuseScore as such.

Just for fun, try this chord 'litmus test'.
Enter as a chord (Ctrl+K) the following - exactly as written here: bb7
Press spacebar and you'll see the chord displayed with a (magically) capitalized B, a 'real' flat sign, and a 7.
That means the chord is 'recognized' and can be transposed correctly.

Next enter nb7 as a chord and you will see it is not recognized as a chord symbol and so cannot be transposed. (The letter 'n' is not a real note name.)

Your posted score shows the 'b' that 'looks like' a flat but if you look carefully it is still a 'b' (text) and not a 'real' (musical) flat sign.
The number sign '#' behaves the same way. Although it may 'look like' a sharp, one must look carefully to see if it was parsed correctly as part of a 'real' chord symbol.


In reply to by Jm6stringer

Yes, I understand the whole concept now. Thank you.

In fact, recently I've been going over the entire Wikifonia collection of 6000+ scores, and have discovered that quite a few of them have been prepared incorrectly, in that ordinary text input was used for the chord symbols in many cases by people who either did not know how to use the program, or else were using another program to make it and did not manage to convert to the XML format correctly by retaining the chord symbols as true chord symbols.

At least I have found it relatively easy to correct the problem,. First, I simply select all of the existing staff text and change the type style to something bold and easy to identify . Then, I can simply input one new cord symbol behind the very first text symbol, using the Ctrl + K shortcut , type the exact same information behind the existing text , and then use the spacebar to go to the next quasi chord symbol and correct that one, and then use the spacebar to advance quickly to the next symbol to be changed. After that, I just select all ordinary staff text, delete it, and what I have left are true chord symbols written with the correct font and at the right type size.

In reply to by ErikJon

Ah yes! ... Wikifonia - as I recall, t'was a not-too-distant cousin of MuseScore.

I've seen lots of Wikifonia scores that were created with MuseScore - many from pre 2.0 versions.
The earlier versions of MuseScore shipped with several xml 'chord definition' files which differed in their required chord symbol syntax - i.e., the "spelling" which was needed for the chord to be properly recognized.
The result was that while simple chords, like 'E', or 'Eb' would always get parsed correctly, chords like Eb-7 might not. It depended on which chord definition file was used.
This resulted in some, though they 'looked like' chord symbols, not being recognized (and therefore not transposed). They printed out with 'b' and '#' for flat and sharp, instead of ♭ and ♯. They often went unnoticed.
Hence the lower case letter 'litmus test' was employed to confirm a chord's recognition.

So.... you may on occasion encounter Wikifonia score(s) where some chord symbols will not transpose (while others in the same score will).


(BTW: Credit to Marc Sabatella who streamlined that old, clunky chord symbol recognition system.)

In reply to by Jm6stringer

Thanks! That was actually my very first significant code contribution to MuseScore, way back in 2011, and that code has held up pretty well. As it happens I'm currently working on an update to that, which will allow you to more easily customize the superscripting of extensions and additional modifiers, so you don't need to resort to modifying the XML files as often:


In reply to by Ziya Mete Demircan

thanks for the informative explanation about how those w i k i f o n i a files can be mistranslated. I will certainly be on my toes from now on any time I have any doubts. I had always taken it for granted that anything that looked like a chord symbol was truly a chord symbol inside as well

As for Marc Sabatella, yes, he has truly been a blessing and a great help to me as I learn to use musescore.

I only wish that I could use the new version 3, and that it would somehow work on Windows Vista because I am not likely to upgrade my operating system anytime soon for many reasons not worth explaining here.

thanks again guys

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