Key signatures transposed incorrectly in parts

• Jul 22, 2015 - 03:06
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
duplicate
Regression
Yes
Workaround
No
Project
MuseScore

Ubuntu 14.04, GIT commit: 48f066c

There seem to be a few facets to this. Here is one way to see a problem:

1) new score, treble clef template, C major
2) add notes
3) generate parts
4) select all
5) notes / transpose
6) key of D
7) OK
8) view part

Resukt: notes are transposed, key signature is not.

This happens because there was no actual C major key signature in the score to transpose. A "D" key signature is generated at the end of Score::transpose(), but it is not applied to the parts.

It's worse than this, actually. The score and part are now out of sync such that if you then add a key signature to the score, it gets added to both score and parts and everything *appears* to be in sync, but somehow it is not. The next transposition will not work either, even though no "C" key signatures are involved. The parts seem permanently out of sync with respect to key signatures as far as I can tell; not sure why. Maybe it's because the key signatures are not actually linked, although it seems in other situations this is not a problem.

However, I am also pretty sure I have been able to reproduce a case where some sequence of key changes and flipping the concert pitch button creates a similar situation where the key signatrues become out of sync even without using Notes / Transpose. I just can't find the steps right now.

Comments

• Jul 23, 2015 - 08:16

From what I see in the time for this issue, there is two steps in the change.

The start point (the test notes in C) is this one:
1start.jpg

- With this Nightly on August 25: 8fb3b5b, all is correct and as expected:
In main score after transposition in D:
2 25 aout correct main.jpg
In part:
3 piano correct 25 août.jpg

- With this Nightly on August 25 always: 534c918
Uncorrect in main score (two unexpected accidentals)
4main score 25 août wrong.jpg
Uncorrect in part (no keysig)
5 part wrong 25 août.jpg

So, the cause is probably here: https://github.com/musescore/MuseScore/commit/f8feaf7c6bfa2e28f8502f3e7…

- The second change (but partial) occurs on December 22:
With this Nigthly: 4a78d5c

In main score, the result is again correct (accidentals have disappeared)
6 main 22 décembre.jpg

But not in the part (no keysig always).
7 piano 22 décembre.jpg
These two previous images reflect the current result (of 2.0.2 eg)

For the cause (of the good, but partial change in december), it's less obvious (many commits: it was the day of the Beta2 release!) but after checking, I "vote" for this one:
https://github.com/musescore/MuseScore/commit/df7ff007e8ff8536d6ea258b8…
To fix: #39901: Undo of concert pitch produces incorrect transposition

Reply

• Mar 12, 2016 - 19:38

I have a local build with this issue fixed. After more testing and familiarizing with git, I will send a pull request.

Reply

• Mar 13, 2016 - 00:42

Partially fixed... Seems this is a bit more complicated and transposition has more problems than what I originally thought.

With nightly b9aa72f:
1. new score with Bb clarinet (concert c key sig.)
2. generate parts
3. flip concert pitch button (now in concert pitch)
4. transpose to G major
- Part incorrect.

1. Repeat steps 1 - 3 above
2. flip concert pitch button again
3. transpose to G major
- Part also incorrect.

Reply

• Mar 7, 2018 - 21:52

Looking at this again. I haven't built yet, but I think the current PR can only fix part of the problem - the last set of steps shown will continue to be a problem. I think that's because when the score is moved into concert pitch and the keysig is removed, the link is broken and nothing will bring it back. So, turning concert pitch back off will make the keysig appear again, but it won't be linked to the part. And now the transpose will fail, and perhaps other operations will too.

I think that we probably need to re-establish link any time we create a new keysig as a result of any transposition. So if a keysig gets created a a result of either notes / transpose or toggling concert pitch or the transpose semitone commands (formerly tied to F2 key), these all need to look for keysigs in linked staves and connect to them. Ideally, we can do this in one place.

Reply

• Nov 13, 2018 - 12:16
Severity S3 - Major ⇒ S2 - Critical
Status ⇒ PR created
Frequency ⇒ Few
Priority ⇒ P1 - High
Regression ⇒ Yes
Reproducibility ⇒ Always
Workaround ⇒ No

Still the case with current master.

Reply