Dynamics with offset move right after save

• Dec 20, 2013 - 12:56
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
2.0

1) enter dynamic marking into score
2) apply horizontal or vertical offset
3) save, close MS, and reload file

Result: dynamic marking is further to the right than before reload.

Dynamics with no initial offset seem not to be affected

Using f8187c9

Comments

• Dec 26, 2013 - 20:55

Confirmed, and the Inspector also shows the discrepancy. That is, apply a horizontal offset of say 4sp to a dynamic, save, then reload. The dynamic now shows an offset of 4.67sp, and is displayed accordingly. Each successive save/reload cycle appears to add another 0.67sp. And it's not just dynamics. I see the same with lyric verse numbers.

Staff text, though, seems unaffected.

Reply

• Jan 25, 2014 - 07:13

Is there any current development on this bug? I am affected for quite a long time now (probably more than half a year) and it is quite annoying with larger scores having many dynamics.

At the moment, dynamics even seem to behave differently; some are moved by 0.66, some only by 0.33.

Thanks for your reply!

Using 391e02c.

Reply

• Jan 25, 2014 - 14:35

I was just pushing someone to take a look a couple of days ago when suddenly all text handling broke with a bunch of changes commited yesterday (eg, dynamics are now huge, adding staff text crashes). I think this needs to be put on hold a moment until all the rest is sorted out, but it's become pretty important for me too.

Insert standard comment about it being inappropriate to use development builds for real work...

Reply

• Jan 26, 2014 - 07:53

Thanks for your reply and thanks for your work, by the way.

... it's just so much more fun to use the development builds (and see all those things improve).

Reply

• Feb 7, 2014 - 04:54
Status (old) active ⇒ patch (code needs review)

After some investigation, I would say that the problem seems to stem from this:

http://musescore.org/en/node/12488#comment-84104

The default positioning for dynamics was fine-tuned - nicely, overall - by adding a small adjustment to the x-position to center the dynamic. However, when writing the file, the "pos" tag that is written includes this adjustment, and this gets read back in on reload as the initial position - to which the small adjustment is then added again.

I don't know enough about how pos is supposed to be used to know the "right" way to fix this. But I can see that for voltas and chordrests, the userOff is written to the file rather than pos. And when I modify the code so dynamics are handled similarly, it *does* fix the problem.

I imagine there is a good reason why pos is used rather than userOff for most element types. I believe pos uses absolute position, so text style is taken into account. Writing userOff would presumably change some aspect of behavior with respect to style. If someone knows and would like to comment, I'd love to understand all of this better.

Meanwhile, though, I would propose taking the following code in Element::writeProperties():

            if (type() == VOLTA_SEGMENT || isChordRest())
                  xml.tag("offset", userOff() / spatium());
            else
                  xml.tag("pos", pos() / spatium());

and replacing the test with:

            if (type() == VOLTA_SEGMENT || isChordRest() || type() == DYNAMIC)

as a possible fix for this issue, knowing it might well break something else.

Reply