Corruption when viewing score with section break in continuous view

• Jan 31, 2016 - 04:12
Type
Functional
Severity
S3 - Major
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Ubuntu 14.04, GIT commit: 699a5ee

1) My First Score
2) Continuous View
3) Add section break to measure 1

Result: initial clef disappears from measure 1. Object debugger shows that both the first two measure are lsited as "Measure-1".

This came up in https://github.com/musescore/MuseScore/pull/2323#issuecomment-177044512. As shown there, you can make other bad things happen too.

Comments

• Jan 31, 2016 - 04:50

I guess having both measures listed as 1 is not a bug; that's a normal function of a section break. Still, the deleted clef is not good, nor are the other glitches described in that discussion.

Reply

• Jan 31, 2016 - 05:10

For the clef, I notice a change on May 12, 2015

- On May 11, with this Nighlty: 9e84592
Result as expected:
11 mai.jpg
- On May 12, with this one: e854154
we receive the current result, with the deleted clef.
12mai.jpg

Reply

• Jan 31, 2016 - 17:54

I'm making a note that the "unwanted full-size treble clef after section break" doesn't happen only for the first measure of a score nor only with the first clef change. Here I've reproduced on latest git 2af1e82 starting with clefs beginning meas 3 & 5 and then adding a section break on end of meas 4. First appears the unwanted treble clef:

dsf.png

Which a few sections later reverts to correct clef:

96321-immediately-revert-to-treble.png

Also note that upon file load, I see the unwanted treble clef.

Attachment Size
clef-change-section-break-cont-meas6.mscz 5.2 KB

Reply

• Jan 31, 2016 - 17:15

Some of these problems correct themselves when toggling to page view and back to continuous. I have an idea that the problem has to do with how clef changes are stored. Because they normally are displayed *before* the barline, they are stored at the end of the measure before the one they actually apply to. That is, what appears to be a courtesy clef at the end of a system is actually the "real" clef. It's the clef at the beginning of the next measure - which is normally displayed only at the beginning of a system - that is the "generated" clef. Probably the places where this happens need to be more aware of section breaks and not rely totally on whether a measure is first/last of a system.

I think that was the main point of the commit referenced above - to make sure a clef is displayed in the measure after the system break even though it actually belongs to the previous measure. It just doesn't quite work right in some cases.

Reply

• Jan 15, 2019 - 00:09

Tommylux...could you try on 3.0? The issue history says that "looks correct with current master" on Nov 16, 2018, which means that should be working in 3.0 release.

Reply