Concert Pitch modifies layout and forgets key signature in one line
Priority
P1 - High
Type
Functional
Severity
S4 - Minor
Status
active
Regression
No
Workaround
No
Project
GIT commit: 7bf8682
See differences in attached screenshots
Attachment | Size |
---|---|
ConcertPitchBefore.gif | 40.75 KB |
ConcertPitchAfter.gif | 55.68 KB |
Comments
None of the staves use a transposing instrument, regardless toggling concert pitch causes a relayout, with system breaks at different spots and to that loss of the key sig in this one particular system. Also related: the score uses 'hide empty staves', without that we only see the (unnecessary) relayout.
I don't understand the bug. Can you attach a file and precise steps to reproduce?
Attached is the zipped "DallaSuaPace.mscz". The file is password protected. Send me an email (robert.scharpf@hp.com) to get the password. Open it and press "Concert Pitch" and observe the changes.
Please don't make this file public!
How do you want the community to help if we can't even get access to a file to reproduce the bug?
So I would need the password nicolas at musescore org and I swear, I will not ask you to send me an email to ask for a password next time you download MuseScore... Seriously... This is childish.
If I attach the file without protection anybody can download it. So send me an email and you get the password.
And so what..? I just sent you an email instead of debugging this issue...
Fine for me.
There are at least two things to this bug.
1/ The fact that concert pitch modify some notes, and then the layout. Going to concert pitch should do nothing to this score since the instruments are in concert pitch. However, starting measure 19 and then 35, a Cb (without accidental) is changed to a B#. It's not correct but it also takes more room in the measure and so the layout is changed. It happens because some notes have a different TPC1 and TPC2 value. I think I can reproduce from scratch:
Is it normal to have a different TPC1 and TPC2 values for the same note in a concert pitch instrument? How does it happen? The score file does feature TPC2 values for these notes in measure 19 and 35.
2/ The number of measures per system is changed by the previous bug and so a new penultimate system is created. This system doesn't have a key signature. That's probably due to the fact that we don't create key signature for hidden staves and at the time we create the key signature, we think that the staff is hidden, but it's the next one. At this moment, we can't know if the staff will be hidden or not :( So I would remove the check here or we live with it since it will be fixed during the next layout.
https://github.com/musescore/MuseScore/blob/d4e22ed0d2944bd361e73d69f26…
I talked a bit with Werner about it.
2/ is ok. We could choose one or the other alternatives for 2.0. So we can also live with the problem. It's something we encounter often, we miss the information at the time we need it... so it might need a very different implementation in the future.
1/ is a serious problem according to him. So he wants to take a closer look before the release of 2.0RC.
This issue, with these steps (as in comment #9)
1. Create a score for flute in G major (F#)
2. Add a Cb, and a second Cb in the same measure, so without flat
3. Press the concert pitch button, nothing should happen.
occurs on September 22.
- With this Nightly (september 20, no nigthly on sunday 21), d9bf96b
I receive a correct result after pressing the concert pitch button (nothing happens)
- With this one: d9331b6
I get:
So: the cause is probably in the previous commit: https://github.com/musescore/MuseScore/commit/58763e6cc5762bb8ee588f674…
To fix: #33366: R key producing notes on wrong lines when used with transposing instrument
Fixed in d990e20891
The current fix solves the case of http://musescore.org/en/node/50316#comment-234481 1/ and 2/ (by always creating key and clef)
However, the file from http://musescore.org/en/node/50316#comment-234286 is "corrupted" in the sense that the notes have different tpc values while they shouldn't. The fix makes it harder to create notes with different Tonal Pitch Classes in a non transposing instrument.
The next commit f9a0f9b5f5 will not save TPC2 for non transposing instruments. So it should fix the previous file after a load and save cycle. It should also prevent the creation of "corrupted" files in the future.
d990e20891 has been reverted in 40fa7d0 ...
True. The second part of the bug - key signature potentially missing at first when a staff reappears after having been hidden - is still open. My understanding is it fixes itself on the next layout.
The first part - certain notes changing spelling on toggling Concert Pitch - should be fixed, at least, to the extent the original fixes did the job. New scores won't have the problem at all as far as we can tell. Scores from earlier 2.0 builds that are already messed up in this way won't be fixed automatically, but will if you open the score and re-save.
I don't understand very well this point: " The second part of the bug - key signature potentially missing at first when a staff reappears after having been hidden - "
Which precise steps to reproduce? Thanks.
Unfortunately, it might be rather difficult to reproduce, as it depends on how the score is laid out on your system. I coudn't reproduce it at all. But I can describe the basic issue
- you need a score that has multipe instruments, and key signatures, and uses hide empty staves
- you need some staves to actually be empty and hence hidden, but not completely empty throughout the whole score - they have to have some notes
- you need to do some operation that moves a measure from one system to another in a way that changes which staves are considered empty on which systems, so that a staff that was previous hidden on a given system because it had only empty measures now appears because a measure that had notes moved onto this system
- when the bug happens, what you will see is that the staff appears but does is missing its key signature
It won't be a new bug, I don't think. It has probabvly existed since before 1.0, although I can't prove that.
A related bug that has definitely existed since 1.x:
1) new score, treble clef template, key of C
2) fill with notes
3) edit / instruments, add alto saxophone (it will appear with A major key signature)
4) hide empty staves
Result: you will see that the space for the A major key signature on the alto staff remains on all systems, even though the staff is hidden on all systems but the first.
These bugs are related in that they both have to do with management of the key signatures on hidden staves. The original bug comes from times when we *don't* create them because we think the staff is hidden; the other comes from times when we *do* create them because we think the staff is *not* hidden.
"Unfortunately, it might be rather difficult to reproduce, as it depends on how the score is laid out on your system. I coudn't reproduce it at all [...]
It won't be a new bug, I don't think. It has probably existed since before 1.0, although I can't prove that."
Ah, that's why I failed. So I cannot locate it, I fear.
Here's a picture to demonstrate what I mean in #17:
As you can see, there is unnecessary space in measure 9, due to the key signature in the hidden alto saxophone part.
I submitted a PR that takes care of this layout issue. Combined with lasconic's earlier commit, this would actually solve the problem completely, at least in theory.
https://github.com/musescore/MuseScore/pull/1878
Just installed GIT commit: 09a32e6.
The problem exists still. Test case (Dalla Sua Pace):
- I saved the old one with a new name and reopened it.
- Turning on Concert Pitch" changes still the layout and even worse the notes! See attachments ConcertPitchBefore2.gif and ConcertPitchAfter2.gif.
- The layout is also changed, more lines.
- The file is marked as changed.
I guess that is why the issue is still open ;-)
As discussed earlier, your file is already corrupt - the different pitches for concert pitch on/off are already recorded in the file. The Concert Pitch button is merely reporting these spellings as they are recorded in the file. But the bugs that *caused* the corruptions in the first place have been fixed (well, the known causes anyhow), so that this should not happen in new scores any more.
But its too late for those fixes to affect already corrupted files. For now, what you would need to do is turn concert pitch mode on, make the necessary enharmonic corrections in that mode using the "J" key, and then re-save. The act of saving the file in 2.0 will lock in the concert pitch spellings and make them apply to both modes.
This will fix the issue of different spellings, which should in turn fix the layout shift that you were seeing (although I can't prove that since the shift didn't occur on my system). There are other underlying issues with how hide empty staves works that could potentially make layout shifts still occasionally be a problem.
Oh, and yes, pressing concert pitch does mark a file changed; that much is not a bug but is by diesgin. t *is* a pretty significant change in how the file is represented internally (it, it is not like scrolling or zooling in or something that just changes the view).
Thanks, I'll apply your recipe to fix my corrupted file.
The PR was closed.
Bump to observe that there is at least still the issue with key signatures on hidden staves taking space unnecessarily as per https://musescore.org/en/node/50316#comment-235831. The code that determines the segment width is checking for hidden staves, but I think at this point in the layout we don't actually know if the staff will be hidden or not. For instrument names, we might be wrong on the first layout but it is corrected on the next, but for key signatures, it just stays wrong. Not totally sure why the difference but I guess these happen at different stages.
No idea if anything else discussed in this issue still applies, but the extra space is unfortunate, I just don't see a simple / safe fix.