Stacking order, autoplace not saved for generated stems
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
In MuseScore3 beta, I found that MuseScore didn't keep the value of Stacking order of STEMS when I changed the value.
I changed the value from 1800 to 3000 at the stacking order of STEMS in Inspector and saved the file, and then I opend the file, I found the value was rewrited to 1800.
Fix version
3.1.0
Comments
when you change the note's value (pitch, duration?) you effectivly rewrite it, including the stem, so it is a new stem and as such uses the default stacking order
In reply to when you change the note's… by Jojo-Schmitz
No.
See these pictures, and try. Stacking order of STEM is Always not saved.
I can confirm. Stems are normally considered "generated" elements, meaning we don't save information about them unless you have customized them. We do this if you've changed anything else - visibility, length, etc - but we don't for stacking order. Also, seems we don't for "automatic placement". But oddly, this doens't apply to all generated elements, it works fine for clefs for example.
Workaround - change anything else about the stem to force it to be considered non-generated (eg, lengthen it by 0.01sp).
Loss of data is not good, but also, if we are to deal with other issues involving generated elements not being saved, like #139846: Leading space adjustment for generated elements lost on save/reload, it may make sense to look at these together.
https://github.com/musescore/MuseScore/pull/4843/commits
fixed here
Is this link correct?
That particular issue is not mentioned in that PR, as far as i can see
Actually https://github.com/musescore/MuseScore/pull/4844
Oops my mistake. That’s the correct PR. Thanks!
Fixed in branch master, commit d6780eb0fa
fix #279245: save stacking order and autoplace for stems and system dividers
Automatically closed -- issue fixed for 2 weeks with no activity.