Deleting key signature doesn't remove courtesy one at end of single-measure system (in Page View)

• Mar 19, 2016 - 02:57
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Starting with a 1-measure system where have a keysignature on next system, e.g.:
1-meas-line.png

If then delete the real keysig, then the courtesy sig remains:

1-meas-line-after-delete-sig.png
However expected behavior is that there should be no courtesy sig if there is no keysig.

Note: also happens if a Horintal Frame (aka HBox) is used to break up a system, for instance if start with:

courtesy-keysig-hbox_add-hframe.png

Then after deleting the real keysig, the courtesy one remains:

courtesy-keysig-hbox_delete-key-sig.png

Note that the courtesy sig will not disappear if add notes to first measure, but the courtesy sig will disappear when add an extra measure to that system, e.g.:

courtesy-keysig-hbox_courtesy-only-dissapears-when-insert-meas.png

Looking at the code, I suspect the reason is because at the end of Score::layoutSystem(), the lines that remove generated elements :

      if (firstMeasure && lastMeasure && firstMeasure != lastMeasure)
            removeGeneratedElements(firstMeasure, lastMeasure);

are not invoked when firstMeasure == lastMeasure (i.e. a single-measure system).

Comments

• Mar 19, 2016 - 06:32

well I traced those lines that removed generated elements with condition "firstMeasure != lastMeasure" all the way back to original github commit 1f9ccfc on May 26, 2012 of layout.cpp:

https://github.com/musescore/MuseScore/blob/1f9ccfcdcedd643f5e12b525b2a…

I don't know how to search further (and I don't want to figure out how to use svn & sourceforge). But it seems that that condition probably goes up pretty far in the past. I'm suspecting that that condition was simply an optimization, but I don't know without being able to read commit history.

Any ideas of specific tests I should add? Can anyone think of negative consequences from removing that condition?

Reply

• Mar 19, 2016 - 16:09

You certainly don't want to remove the generated elements at the *start* of the measure first measure of the system, presumably that is what we are testing for. But probably just better to make sure we are smart about which elements we actually remove, which I assume is the case.

Reply

• Mar 20, 2016 - 01:43

well the function removeGeneratedElements() itself is being smart about not removing generated Clefs or Keysigs at the *start* of the first measure of the system, here :

|| ((el->type() == Element::Type::CLEF || el->type() == Element::Type::KEYSIG) && el->generated() && seg->tick() != sectionStart->tick())

Maybe that concern was the original intent of the "firstMeasure != lastMeasure". But since that logic is being handled inside removeGeneratedElements (which is where that logic probably should be handled), then I should be safe to remove that condition "firstMeasure != lastMeasure" when layoutSystem calls it.

I should note that the only other place where removeGeneratedElements() is called is inside Score::layoutLinear(), and it gets called *without* any condition check "firstMeasure != lastMeasure". And the behavior in cotinuous view is indeed correct (i.e. debugger shows the "genated" treble & bass clefs at the start of a single-measure piano score are not removed).

Reply

• Mar 20, 2016 - 01:51

except now with my code change, then if indeed have a single-measure *SECTION*, then that generated clef at the start gets removed... opps-section-start_150dpi__.png

...I'm thinking removeGeneratedElements need to differenate between "start of section" and "start of system".

Reply

• Mar 20, 2016 - 02:10

anyway, the current git master code has that same problem when viewing in continuous mode, see #102791: generated clef/keysig at beginning of single-measure SECTION is incorrectly removed in continuous view. Note that continous view calls removeGeneratedElements without any conditions at all , and hence removes that initial generated clef in single measure system.

So the solution to me is remove the firstMeasure != lastMeasure checkout from the caller function layoutSystem, and instead put the necessary logic inside removeGeneratedElements.

Reply

• Mar 20, 2016 - 02:12
Title courtesy key signature at end of single-measure system not removed when delete real keysig ⇒ courtesy key signature at end of single-measure system not removed when delete real keysig (in Page View)

Let me clarify in the title that this issue is for Page View, while the other issue is for Continous View.

Reply

• Jan 27, 2017 - 14:41
Title courtesy key signature at end of single-measure system not removed when delete real keysig (in Page View) ⇒ Deleting key signature doesn't remove courtesy one at end of single-measure system (in Page View)

I can't check 3.0 nightlies, but I can reproduce in other versions.

1. Open attached score (produced in 2.0.3.1).
2. Delete key signature in bar 2.

Result: Courtesy key signature at the end of bar 1 remains.
Deleting key signature doesn't remove courtesy one at end of single-measure system (in Page View).png

Using MuseScore 2.1 Nightly Build 75b66fd - Mac 10.11.6.

Attachment Size
Deleting key signature doesn't remove courtesy one at end of single-measure system (in Page View).mscz 3.96 KB
Deleting key signature doesn't remove courtesy one at end of single-measure system (in Page View).png 20.74 KB

Reply