No space between barline and note if invisible key signature present
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.0.489510097, revision: 28aa7ba
The attached score looked OK in version 3.5.2. However, in 3.6.0, the note left margin in measure 2 is virtually non-existent. Resetting makes no difference.
Attachment | Size |
---|---|
beam_issue.mscz | 14.76 KB |
Fix version
3.6.1
Comments
Confirmed
The cause is a disabled key signature at the beginning of the measure on the tab staff only. Not sure how that got there, but anyhoe, presumably the fix for spacing around invisible key signatures is what triggered this.
Solution here is to click the double bar on the tab staff then press Alt+Right to select the invisible key signature, then press Delete.
Meanwhile, though, you can reproduce this scratch with any score that is already in C major by adding a key change to C major, which won't display ("naturally"). Or for that matter, adding any key change then marking it invisible.
https://github.com/musescore/MuseScore/pull/7328
Fixed in branch 3.x, commit c8d326ad88
_fix #315636: no space between barline and note with invisible signature
Resolves: https://musescore.org/en/node/315636
When code was added to better handle invisible key or time signatures
at the beginning of a score,
this inadvertently affected spacing between barline and first note
if there were invisible key or time signature changes later.
The spacing was never actually correct here -
it was controlled by the key or time signature margin -
but it more or less worked and scores depended on it.
The problem is that the changes made involved
setitng the width of these invisible segments to 0
and skipping them.
Whereas previously, they got processed enough
to yield some space betwene the barline and first note.
The firx here is just to limit the effect of the previous change
so not all segments with all elements invisible,
but only those in system header measures,
or segments after the beginning of the measure.
Thus we continue to handle beginnings of scores and systems well,
and also courtesies at the end of measures.
But we revert to the previous behavior for key or time signatures
at the beginning of measures that are not headers.
Again, it wasn't ideal, but it basically worked,
nand now works again the same way.
I left TODO's in the code to indicate something
of what would need to happen to fix this "for real",
with the space controlled by barNoteDistance as the user expects,
rather than depending on the key or time signature margins.
A quick attempt to implement this led to problems
that convinced me to put it off until a larger scale rewrite
of the spacing algorithms as a whole._
Fixed in branch 3.6.1, commit d0fc8e9739
_fix #315636: no space between barline and note with invisible signature
Resolves: https://musescore.org/en/node/315636
When code was added to better handle invisible key or time signatures
at the beginning of a score,
this inadvertently affected spacing between barline and first note
if there were invisible key or time signature changes later.
The spacing was never actually correct here -
it was controlled by the key or time signature margin -
but it more or less worked and scores depended on it.
The problem is that the changes made involved
setitng the width of these invisible segments to 0
and skipping them.
Whereas previously, they got processed enough
to yield some space betwene the barline and first note.
The firx here is just to limit the effect of the previous change
so not all segments with all elements invisible,
but only those in system header measures,
or segments after the beginning of the measure.
Thus we continue to handle beginnings of scores and systems well,
and also courtesies at the end of measures.
But we revert to the previous behavior for key or time signatures
at the beginning of measures that are not headers.
Again, it wasn't ideal, but it basically worked,
nand now works again the same way.
I left TODO's in the code to indicate something
of what would need to happen to fix this "for real",
with the space controlled by barNoteDistance as the user expects,
rather than depending on the key or time signature margins.
A quick attempt to implement this led to problems
that convinced me to put it off until a larger scale rewrite
of the spacing algorithms as a whole._
Automatically closed -- issue fixed for 2 weeks with no activity.