Positioning of slur moved using mouse not preserved upon paste

• Oct 5, 2014 - 19:04
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

When I paste a passage from one line to a line below it many, but not all, of the slurs appear as if they were on a line even farther down the score.

See screencam video for demonstration

http://youtu.be/si7KmDybb0w

score used in video attached.

Attachment Size
Dotzauer BkII pg2_112 for test.mscz 6.52 KB

Comments

• Oct 5, 2014 - 21:02

I think have understood what happens. The slurs that are "lost" are the ones you have manually moved (with the mouse) before placing them again, is not it?

If I delete the slurs on your file, and I put them back without affecting their "Auto" position, everything goes well.

I can replicate on other file.

In this screenshot, if I don't anything for the slur (first measure), it's correct.

In the second measure, I have moved the slur, before returning it to its original place more or less, with the mouse. And in this case, indeed, copy and paste goes wrong.

BUT, if I use the Inspector to reset the horizontal et vertical offset, the copy-past is correct.
slurs flute2 .jpg

The bug is already former. After first tests, it's correct on July 17, and incorrect (with mouse) in August 5. I try to be more specific shortly.

Attachment Size
slurs flute2 .jpg 43.82 KB

Reply

• Oct 5, 2014 - 22:05
Title paste incorrectly places many slurs ⇒ Displace slurs with the mouse causes a defective copy-paste

So, after investigation, that issue, exactly in the terms described in the previous screenshot (no moving, moving with mouse, moving with mouse and reset via inspector), is appeared between July 19 (no contributions, the Sunday 20 July) and this commit, correct:

https://github.com/musescore/MuseScore/commit/8cc66dd9cf6e53ebe7cb2cd20…

and July 21, with this commit, incorrect. https://github.com/musescore/MuseScore/pull/1044

After watching, it may well be that the answer lies in the following commits (in order of "preference", even if the code is unfamiliar to me, as you know now!) :(

- https://github.com/musescore/MuseScore/commit/e184ee471c185f899185a9111…

- https://github.com/musescore/MuseScore/commit/17910f74412b6fadf4df0cf8b…

- https://github.com/musescore/MuseScore/pull/1051/files

Reply

• Oct 7, 2014 - 00:35

So, steps to reproduce:

1) open attached score
2) drag second slur upwards
3) copy & paste both measures from first staff to second

Result: first slur is copied intact, second has an incorrect offset (it will appear as if we had dragged it downward instead of upward, or as if it were attached the something on a staff below the actual destination).

Reply

• Oct 26, 2014 - 19:54

I forgot to attach a score to my post above with the steps. Try the one attached to this comment, using the steps in the above comment.

Not sure if either of these are related, but:

1) upon copy & paste of a slur from staff to another, the _track2 is not set correctly in the destination (it shows as having the _track2 of the source). I thought maybe it was just because it is not set here:

https://github.com/musescore/MuseScore/blob/fc3ea8e43459c2c371352ac9b91…

But adding a call to setTrack2() doesn't help. I don't know enough about such things to be comfortable digging in much deeper. But FWIW, if you save & reload, it gets set correctly.\

2) if you copy and paste from one staff to another with a different clef (or just a different spot in the same staff where a different clef is in effect), slurs are lost.

Attachment Size
slur-staff-copy.mscz 1.51 KB

Reply

• Nov 6, 2014 - 12:37

Confirmed for ties, in a new score also.

1. Create a score with standard staff + linked tab staff.

2. Enter two chords -> select the first ->Press "+"

Result: the ties are wrong in tab staff.
ties.jpg

Attachment Size
ties.jpg 9.17 KB

Reply

• Nov 6, 2014 - 12:49
Title Displace slurs with the mouse causes a defective copy-paste ⇒ Positioning of slur moved using mouse not preserved upon paste

Better title?

Reply

• Nov 6, 2014 - 13:18

Probably, that was the problem before the fix, now we see something different though.
Not sure whether to keep this here as a regression or open a new issue about it?

Reply

• Nov 6, 2014 - 14:38

Looking at the code for the original fix, this is actually a pretty significant change, and I won't be surprised if there aren't a couple other bugs left to be discovered (let's be sure to test save/reload). As it is, I suspect the two different cases of incorrectly positioned ties - one in older scores, on in newer scores but apparently specific to linked staves - will turn out to have different causes/fixes.

So I think it probably makes sense to register new & separate issues, although that's just my opinion.

Reply

• Nov 6, 2014 - 14:38

Unfortunately i had to change the anchor of slur segments from system (which is wrong) to staff which changes the file format. On import of old files for now i reset all user tweaking for slurs on all staves except the first one. I am working on a real solution for import of old files...

#11 seems to be a regression.

Reply

• Nov 6, 2014 - 15:18

@cadiz1: we know which commit is the culprit (and you are right, this is the one).
Werner is on it, so for now no new issue needed I guess

Reply