Album with a score with a key sig != Cmaj with one with a key==Cmaj lose keychange

• Nov 29, 2014 - 16:40
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
album

be027cd31c

  1. Create a score in G major and save
  2. Create a score in C major and save (Note that with the debugger shows a key sig in first measure)
  3. Open both scores in album
  4. Create score

      5. Actual result: The joined score doesn't have a C major in the second section.
      Expected result: The joined score should have a C major in the second section.

      It works for other key signature. Is it again one of this case where we need to special case C major?

Attachment Size
Gmajor.mscz 2.44 KB
Cmajor.mscz 2.42 KB

Comments

• Dec 21, 2014 - 09:23

Continued testing with Nightly "correct" (94c9022, November 28), I just noticed something unusual.

By joining four scores: D + C + G + C, we find that the change in C is successful. But surprisingly, the latter measure, which has a "natural" (without my intention) system break, is in G.
test album.jpg

Going (by chance) in Layout -> Page Settings -> Scale -> reducing slightly the Space Staff (default 1.764mm to 1.700mm), another surprise: the F# is gone.
Layout Staff space.jpg
And if I give again the value of 1.764mm, it returns!

Useful investigation maybe? Does it recalls another issue, resolved or not?

EDIT: from the "false" Nightly (d85bee2) - the behavior is the same with the current nightlies-, we have this result: unsuccessfull change to C (and the layout is different with section break + system break).
current nightly.jpg

Attachment Size
test album.jpg 24.4 KB
Layout Staff space.jpg 19.18 KB
current nightly.jpg 54.51 KB

Reply

• Dec 21, 2014 - 11:30

I'm trying to track down the culprit (I mean the presence of the sharp in the last measure and which switches according to layout). He prowls somewhere between August 24 and August 25...
Stay tuned! :)

Reply

• Dec 21, 2014 - 13:40

So:
I do not know if it is the culprit, or one of the culprits, related directly or indirectly to the first issue. Anyway, here is what I have observed about this sharp, present or not in the last measure after layout.

- On August 25, I see this on the Nightly (and on some earlier): https://github.com/musescore/MuseScore/pull/1217

Album 25 août première N.jpg

Note that by default the first option is always selected in Accidentals (I always checked this)

Album 25 août première N bis.jpg

- On August 25, still, I see this important change on the Nightly (and followings ): https://github.com/musescore/MuseScore/commit/f8feaf7c6bfa2e28f8502f3e7…

Album 25 août deuxième N.jpg
After a layout with Staff space (see details in comment #3) , the result is correct.

Album 25 août deuxième N layout change.jpg

There is a lot of activity on that day (the day before the Beta1 release...). Between these two Nigthlies, there have been few commits.

I looked. In addition of the second mentionned Nigthly, I propose a selection of others commits : to check of course with a particular care, if others?

- https://github.com/musescore/MuseScore/commit/9b27beff0c003f3ddabdcf884…

- https://github.com/musescore/MuseScore/commit/55f2c216b5f9dada90eaf5c1c…

- and two others (less probable?) https://github.com/musescore/MuseScore/pull/1211

- : https://github.com/musescore/MuseScore/commit/d5cb57663c76cbdfeaa304e3b…

Attachment Size
Album 25 août deuxième N.jpg 30.46 KB
Album 25 août première N.jpg 30.75 KB
Album 25 août première N bis.jpg 61.01 KB
Album 25 août deuxième N layout change.jpg 25.82 KB

Reply

• Dec 23, 2014 - 06:51

Great :)
Does my research has helped (or not) to understand this issue?
Too bad the fix it is not in Beta2. What was the reason of the presence or absence of the F # in the last measure according the layout? I found, but still not understood the cause!

Reply

• Dec 23, 2014 - 16:06

Your research is always aporeciated :-)

The *cause* of the problem in this case was obvious enough from the beginning. We no longer store C major key signatures at the beginning of a score, since they are invisible. This means we need do handle that case specially any time it comes up, and this case got missed. In addition to just copying key signatures from the old score to the new, we also need to create a brand new C major key signature here, otherwise, the old one just continues to be in effect.

I beleive the cause of the appearing & disappearing F# is that while the C major at the *beginning* of the score was skipped (because there was nothing there to copy) any key signatures *within* the score got copied correctly. And "sometimes" I guess there is an actual C major key signature after a line break, so the copy works, but other times there is not. Ideally, the code should work either way. And now that we are setting the initial key correctly, it should - or at least, that will be the case once tmy fix (or another similar) is merged.

BTW, I did try to fix it for Beta 2, but the code is delicate and it just took me too long to get it working correctly. It's not *that* bad though - everything should be fine if you add a C major key signature after joining the scores. Nothing has been corrupted; we're just missing key signatures, as far as I know.

Reply

• Dec 23, 2014 - 16:26

adding that gotten list C major keysig is of course working , and possible if you join just a handful of scores. It'd be way too painful in my use case of joining some 400 scores ;-)

Reply