clef and key are erroneously shown further (in lead sheet style), althoug I didn't check 'create clef/key on every staff'

• Aug 19, 2019 - 19:36
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Randomly
Status
closed
Regression
Yes
Workaround
Yes
Project

Comments

Status needs info active
Priority P1 - High

I see what you mean. I can reproduce in this score, and in another I tried making, but then not in another. Right now I'm not sure what the trigger is, but it doesn't seem to be the transposition or the existence of parts as I initially suspected.

I have steps:

1) new score, treble staff, key of Ab, 32 bars
2) add line break after measure 4
3) format / style / page
4) disable clefs & keys for all systems
5) verify the clef & key disappear on second system as expected
6) enter note into bar 1

Result: clef & key reappear, and layout is messed up:

no-clef-key.png

I suspect it is that we are not correctly honoring the style setting in the part of the code that handles trying to figure out if another measure will fit on the sytstem.

Some additional info / questions:

It seems this problem only occurs on the second system of the score, and it only occurs after some editing operation. Meaning, it always goes away when you reload the score, but returns one the first subsequent editing or save operation (anything that triggers a layout of those first two systems).

Assuming you are not seeing this in any other cases, then I see how to fix it and it's extremely simple. But I do want to make sure there isn't some other case I am missing - some case where the problem happens somewhere other than the second system, or where it doesn't fix itself on reload.

Status PR created fixed

Fixed in branch master, commit ccb8fe0e02

_fix #293531: clef&key appear on second system after layout with gen clef&key disabled

In https://github.com/musescore/MuseScore/pull/4866 I added code
to better handle the detection of the end of the layout range.
Part of this was to re-establish the header in the first measure after the end of the range.
But my code mistakenly passed in lc.firstSystem as the firstSystem parameter.
Thus it treated the second system as if it was the first,
since lc.firstSystem was set based on the system we just completed,
not the system we are about to consider.
Fix is to calculate when this new system is actually the first system of a section or not.
I calculate this the same way lc.firstMeasure itself is calculated._

Fix version
3.3.0