User offset on slur applied incorrectly on save/load

• May 23, 2015 - 22:57
S3 - Major

Ubuntu 14.04, GIT commit: 4633659

1) new score, two staves
2) add notes to bottom staff
3) add slur
4) apply 1sp vertcial offset to slur using Inspector
5) save
6) reload

Result: slur is much too low. Presumably the offset is being applied to the wrong position - relative to staff rather than to system. The offset seems fine in the file itself, so it's a problem in read, not write, I think.

I know bugs like this have been report, fixed, and broken again over the past year or more. See #35466: Positioning of slur moved using mouse not preserved upon paste for a very similar issue that was fixed a few months ago. Except in the current case, copy/paste actually works fine, which is kind of surprising since it normally use the same read as loading a file.


I can't reproduce with this Nightly: 93d1b48

1) New score for Flute and Bb Clarinett
2) I apply -1,00 sp vertical offsett (same result with positif 1,00 sp) on the first slur
3) Save-Reload
Result: as expected. The slur remains at the same location, and the vertical offset value in Inspector is correct -1,00 (or 1,00).
same result.jpg
The test file: test file.mscz

What I messed?

Really? How strange. For me, loading that file produces this:


My build is from source that are one commit earlier than yours, but that *shouldn't* have affected anything here.

EDIT; just to be sure, I updated to latest master and rebuilt - no change to the result shown above. BTW, the apparent glitch at lower left is just a little bit of the measure number on the next system creeping into the screenshot.

Yes, I receive that also: slur is at a vertical offset value of 9,50 in Inspector.
1) After pressing the reseat button.
2) Changing again the vertical offset e.g. 2,00
3) Save - Reload

Result: as expected, with the same location of the slur (2,00)

Ditto from scratch ("My First Score" + Add score Flute) and same "initial" steps. Don't know what happens.

Hmm, with my score, even if I reset and change the offset again, then save & reload, I see the same incorrect result.

However, I can also make your example fail - if I add a title frame. If I load your test file, add a title, then save and reload, I see the same problem.

Well, works always fine after save & reload, as expected, after adding frames (vertical, horizontal...) or not, and with my file and yours ( debug may be involved, as some issues, in my memory?)
For now, as I can't reproduce, I give up ...

I'm 4 revisions back (I'm at Jimka's ornament submission) on Win8.1u1 and I can't make things fail either. There's some subtle detail that's missing.

Do you mean, even loading the file I posted, you don't see the slur way below the notes? Or do you mean, you can't create the problem from scratch?

I saw the 9.x slur offset in your file, as cadiz1 did, but could not duplicate the issue from scratch. I adjusted many different settings and tried many combinations of things but no go.

Status (old) active closed

OK, wow, I figured it out. The issue is caused by the fact that I am running MuseScore with the "-t" option (used to generate the automate mtests), which has the effect of stripping out some of the version information. So the files I write are showing as mscVersion 200 rather than mscVersion 206, which in turn causes MuseScore to think they were written before the change in November 2014 to store slur position relative to the staff rather than to the system (to fix the issue I referenced earlier - #35466: Positioning of slur moved using mouse not preserved upon paste).

So, this is not an issue with slurs at all, but an issue with the version information written when using the "-t" option. I'll file a new issue for that.

Thanks for providing the working version score that allowed me to (eventually) spot the relevant difference!