Layout shift of slur after reload

• Nov 22, 2019 - 20:01
Reported version
S3 - Major

Certain customizations of slurs aren't honored upon save and reload. It's difficult to define the exact steps since sometimes (for the most part) custom slurs work just fine, but sometimes they don't. It seems related to changing multiple nodes and having auto-place do a few extra auto-motions after custom changes. This problem seems to be especially manifest when finger-text is present below/above a slur. To clarify this instead of merely mention it, I've included a mscz file that has the erroneous saved results upon loading, yet also I include a screen capture of the changes performed upon the slur (used redo here so there's no mouse showing), demonstrating how it appears before saving and reloading.

1) Here's an animation showing a slur being placed across a measure, with the addition of the left-terminal being moved upward a bit, and then the right-terminal being moved down and slightly to the left above the note-head. It seems that auto-placement does some extra work here by pushing upward the center area. The result is acceptable and then saved to file:


2) Upon saving this and reloading: the result gives what is shown in the following screenshot:


Something wasn't registered in saving or in loading, or some operation of the autoplacement wasn't stored/interpreted correctly...

If it helps at all, an mscz of the final file is included here which includes two measures: the first is the same notes and fingering text but with the default autoplaced slur, and the second measure is the customized slur shown to be performed in the gif, yet looks as the above picture with the slur crossing through the fingering text in the middle. Hope this bug can be fixed soon.

Attachment Size
slurcustom_reload.mscz 4.54 KB


Title Certain Slur customizations not honored upon save/reload Layout shift of slur after reload

I don't think anything was actually lost - I think it's just that the initial layout upon load doesn't do the whole job, because both fingerings and slurs are done in stages so you can sometimes see glitches like this on initial load. As you can see, it fixes itself on the next layout. So it's not quite as serious as it may first appear - just a temporary glitch. Still, not good if you can trust printing right after loading.

In other cases like this, I've been tempted to just force two layouts on load but so far we haven't done that.

In reply to by Marc Sabatella

Nice observation about its being fixed upon next layout (e.g., move any note around, not even of the same measure in question, and the slur is updated to how it was before reloading): didn't notice that before.

It seems to me that printing will often be performed at a later time after a score has been saved, meaning a user may start up MS, open up a file, and print it without making any adjustments, expecting the layout to be exactly as it was when finishing up the file in a previous session. This in turn reiterates the need to get the load-layout algorithm fixed up to not confuse users with inconsistencies with this type of workflow. a large score, the complete layout isn't updated...

This is part of the design that increases the speed of layout when you make a change in the score. This has proven to require much TLC to prevent other problems from showing up. There are currently a couple of issues open were items do not update when they should and several more that have been fixed.