Lines: custom properties are lost when layout changes
Reported version
3.3
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
by design
Regression
No
Workaround
Yes
Project
MS 3.3 / Win 10
Open the attached file. Copy the first measure to a blank measure.
Expected result: Copy should be an exact duplicate.
Actual result: The custom position and length of the line in the copy is lost. Not only that, but the same is lost in the original measure as well.
This also occurs if system breaks are added to a score which has lines with customised positions and lengths.
Similar issue, #296487: Customized line continues to inherit customizations after changing systems?
| Attachment | Size |
|---|---|
| copy_lines.mscz | 16.5 KB |
Comments
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.10429, revision: 42da9ca
Still present in this nightly.
I believe that I found the root cause of the 'issue'. If you paste the measure in the same line(staff) the width of all measures decreases. Naturally, this offsets the placements of elements (including disrupting the original measure). If you paste the measure on a different line(staff) the original measure stays the same but the pasted measure is by default leaner (I need to apply a 1.6 layout stretch to have the exact same result as the original). So this is not really a bug (maybe having the pasted measure be leaner is?). The only way I can think of to solve this issue is by having a copy mode that does not automatically change the layout.
Workaround: Change the layout stretch in the measure's properties
Wouldn't this be related to or even a duplicate of #317163: Dashed volta lines come back as continuous after the score is saved.?
Doesn't seem too likely, based on the description, but FWIW, I can't reproduce this to check for myself. The customizations are preserved as expect in 3.6.2.
If someone can still reproduce, can the steps be clarified?
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021803, revision: 3224f34
Expected result: The start and end points of the text-line should maintain the same relative positions.
Actual result: The start and end points of the text-line are now way out of proportion to those in the original line.
They do keep the same relative position. The original start point of the line is 3.0 to the left of the start note, and it remains so regardless of copying or adding breaks or other layout changes. MuseScore has no way of guessing you actually mean that 3.0 sp offset to mean something in terms of proximity to other elements. If you wanted the line to appear near the B, you should attach it to the B, not attach to the D then move it to a position than only just happens to be close to the B in the current layout. Same for the end point - if you wanted it to align with the D, it should have been attached to the D directly, not attached to the G# then moved to a position that just happened to be close to the D in the current layout.