Implied C major key signature at beginning of score does not transpose, corrupts on create new score
Ubuntu 14.04, GIT commit: f78aca0
Another situation where we are missing a special-case for missing C major signatures, I guess:
1) create score for flute and alto saxophone, C major (concert key)
2) add some notes to both staves
3) save / reload
4) select all
5) notes / transpose
6) key of F
7) OK
Result: all notes transpose, as does the key signature for the alto sax staff, but the flute staff key signature remains C major.
Step 3 - save/reload - is necessary because without it, the flute staff actually receives a C major key signature. But on the save / reload, it is removed. There are other ways to remove it as wel, of course, like navigating there via Ctrl+Shift+Alt+Left/Right and pressing Delete.
BTW, it doesn't matter which staff is on top. But there does have to be a second staff with a key signature in order to reproduce the bug. Same thing happens if the key signature on the second staff is the result of adding a "local" key signature as opposed to it being a transposing instrument.
Comments
OK, now here it really gets weird.
After doing the above, with the badly-transposed score still open do the following:
1) select all
2) ctrl+n to create a new score
3) skip to second screen
4) add a single flute staff
5) next screen
6) double click the "Db" key signature in the wizard
Result: the key signature is applied to the currently open score! But not correctly; you see it only on systems after the first, and if the layout changes as a result (as it likely will), you will see key changes mid-system (presumably corresponding to the location of the original system breaks).
It is possible these bugs are unrelated, but so far I can't reproduce this second bug except after reproducing the first.
I can't reproduce with f78aca0
![flute sax.jpg]( "flute sax.jpg")
After creating score for flute-Saxo: test 1 flute sax.mscz
Then, save-reload,
I receive the good key for both instruments: test 1 flute sax after transpose.mscz
![flute sax2.jpg]( "flute sax2.jpg")
Looks like you switched to concert pitch mode. Don't do that. Leave concert pitch off, so alto saxophone staff displays using three sharps.
You wrote in step #1 ("concert key") So, incomprehension apparently.
![test 2.jpg]( "test 2.jpg")
Now, I receive this:
I go trying to locate, if possible.
Wow...I go back in time, and I see this curious thing on September 1 when creating the score.
Ok for the flute. But for the sax, I input the first G. And the following notes, only with R key! :(
Not very good...
I continue...
Yes, when I wrote "concert key", I didn't mean to *switch* to concert pitch mode. I meant that I wanted you to select C major in the dialog, which *is* the concert key, meaning it would show up in the alto part as A major. Sorry I was unclear.
There were indeed bugs with the "R" key with transposing instruments a few months ago - see #33366: R key producing notes on wrong lines when used with transposing instrument. But as far as I can tell, it should all be working OK now.
So, for the moment, between August 16 (ok after transpose) and september 1.
![august 16.jpg]( "august 16.jpg")
But for the sax with R key... :(
I cannot reproduce this (for sax) with Beta2: so, other issue fixed since?
I continue... :)
Between August 22 and August 26.
I continue, stay tuned...! :)
So, after investigation and some effort also (!), I can say now that this issue appears on August 25
- Between this Nightly, correct after transpose: 8fb3b5b
![on 8fb3b5b August 25.jpg]( "on 8fb3b5b August 25.jpg")
- And this one (so: likely implicated ? with "transpose") : f8feaf7
![on f8feaf7 August 25.jpg]( "on f8feaf7 August 25.jpg")
Thanks for the analysis. That commit is what caused this particular series of steps to result in this problem, but the basic problem is more fundamental. I think we understand the issue well enough at this point to know what causes it and what needs to be fixed.
After further investigation, I notice that the first issue (see first message and results on comment #9: so, change on August 25), and the second issue (read comment #1) are unrelated.
The second issue (adding new score flute + Db keysig in wizard) appears on August 20-August21
- "Correct" with this Nigthly: 730b5cd
![1 transpose on 7300b5cd August20.jpg]( "1 transpose on 7300b5cd August20.jpg")
![2 add new score flute on 7300b5cd.jpg]( "2 add new score flute on 7300b5cd.jpg")
Transpose ok
Second step (add new score flute and keysig) Notice the C# in saxo staff
- False (in the sense of the new keysig appears from the second system only) with this Nightly on August 20 (for hour, I have: 00:08: so: depend for the date, 20 or 21) : 8a0fd79
Transpose ok
![3 transpose on 8a0fd79 August 21.jpg]( "3 transpose on 8a0fd79 August 21.jpg")
Second step
![4 add new score flute on 8a0fd79 August 21.jpg]( "4 add new score flute on 8a0fd79 August 21.jpg")
After checking, the cause is maybe here? https://github.com/musescore/MuseScore/commit/8547e277341be299a5199a8fd…
To complete, note that, for the "second step", I receive this in the Nightlies of August 25
mentionned above.
-Transpose ok, but not the following ("second step"), with the Nightly August 25 8fb35b
![5 add new score flute on 8fb3b5b.jpg]( "5 add new score flute on 8fb3b5b.jpg")
- False on the Nightly August 25 f8feaf7 (failure with transpose, as already reported in comment #9 for the first issue)
![wrong on f8feaf7 August 25.jpg]( "wrong on f8feaf7 August 25.jpg")
Currently, and to finish, the result on Beta2 and last Nightly is this. Note the absence of courtesy keysig (I always used 16 measures in my tests). Interesting to know why and where? If more questions, I can help.
![7 add new score flute on beta 2.jpg]( "7 add new score flute on beta 2.jpg")
And for the courtesy keysig, I received this:
- with Nightly October 19: dc48ff5
![courtesy on dc48ff5.jpg]( "courtesy on dc48ff5.jpg")
(notice: no nigthly on october 20, and one only on October 21)
- So, with this result (the current result always), this one on October 21 is most likely implicated? c51599b
Fixed in 9abad76910
Original bug does indeed seem fixed, and the unnecessary C major key signature is no longer generated.
The bug mentioned in #1 is not fixed, but it does appear to be unrelated, so I have filed it separately as #43521: Double click key signature in new score wizard affects current score.
Automatically closed -- issue fixed for 2 weeks with no activity.