[trunk] Section break and courtesy clef
r3689
- Create a picollo score
- Add a line break and a section break after 6 measures
- Change the clef on the second line to F clef
Actual result : a courtesy clef is added at the end of the first system.
Expected behavior : If I'm not wrong the goal of a section break is to create a new independent section in the score and so the end of first system should not have courtesy clef, time signature nor key signature.
Not tested with time signature because of #7576: [Trunk] Crash on changing time signature
Comments
This was an idea some time ago. In practice, as courtesy signatures for key and time changes now can be individually turned off or on, their relevance for section break is lower.
It is true that courtesies for clefs cannot be turned off/on (yet), but they should.
About section break, improvements could also take into account this feature request .
M.
I tend to agree with Lasconic, that a section break should do what you would expect to happen if you start a new movement in the same file.
I believe this issue and this other issue are connected.
I think both descend from a design decision: when a clef change occurs at a measure boundary, the new clef is placed at the end of the previous measure rather than at the beginning of the new measure (I'm speaking here of the internal data structures, not of score as it is displayed on the screen. Also, if the clef change occurs in the middle of the measure, no problem shows up).
On the surface, this is consistent with the 'normal' score look: the new clef is drawn BEFORE the measure bar. And, if the change occurs in the middle of a system, there are no problems.
However, if the change occurs at a system boundary, the consequence is that the clef which, in the displayed score, appears as a courtesy clef is actually the 'real' new clef and the clef drawn at the beginning of the next system, apparently the new clef, is actually a system generated element. Whence:
a) if a section break occurs in between, it cannot detect the clef change (already occurred before the break) or turn off the 'courtesy' clef (which is actually the new clef and has already been inserted) => this issue;
b) the clef at the beginning of the new system, being a generated element, has no config. properties => the other issue quoted above.
This is different from how time and key changes are managed: they are stored with the NEW measure and then both issues above are automatically (well, ALMOST automatically) dealt with.
My suggestion is to move the internally stored new clef from the end of the previous measure to the beginning of the new measure (where it conceptually belongs, engraving practice notwithstanding; this would immediately solve both issues with the exiting code) and to manage explicitly the case of a clef change occurring in the middle of a system, drawing it before the measure bar.
(As this involves some non-trivial re-factoring and raises some file structure backward compatibility points, I do not feel confident enough to attempt to implement this suggestion myself...)
Hoping it can be useful,
M.
Again in rev. 4264 (and some revisions before it).
This issue has been fixed for some time, but reappeared again since a few revisions. As stated above, it derives from this other issue , which also re-surfaced recently.
M.
This seems to have been fixed some time ago? As far as I can see, time signatures still have issues #58496: Section break doesn't reset courtesy time sig, but clefs and key signatures work correctly.
Actually, I *can* reproduce one interesting issue with clefs:
1) new score, treble clef template
2) add line break after measure 4
3) change clef in measure 5 to bass clef - courtesy clef appears as expected
4) add section break to measure 4 - courtesy clef disappears as expected
5) now change clef in measure 5 back to treble clef
Result: courtesy clef appears.
It appears a courtesy clef appears any time the "new" clef is the same as the old. I can change that clef to bass, tenor, etc and no courtesy clef ever appears *except* when adding a treble clef.
Removing the last clause of the condition here would solve it
https://github.com/musescore/MuseScore/blob/master/libmscore/clef.cpp#L…
It has been introduced in this commit
https://github.com/musescore/MuseScore/commit/d24c1fecf0b80eb745a609b32…
Not sure why we exclude "changes to the same clef"? Anyone knows better?
Well, from what I see in time, this is a very former issue.
I can always reproduce it since almost a year now ....
These images below were made with this Nightly on May 19: 56177c3
And I get exactly the result described in comment #6: if I drop the same "original" clef in measure 5, the courtesy clef appears.
If I choose a different clef, no courtesy clef appears.
FWIW, I don't understand the reason for that line either.
Ok that's two of us. Let's remove it.
Fixed in 45f835174e
Automatically closed -- issue fixed for 2 weeks with no activity.