Layout shift of slur after reload
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 |
Comments
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 I don't think anything was… 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.
In reply to Nice observation about its… by worldwideweary
Whoa, it might be more serious. I have proof that in a large score, the complete layout isn't updated upon moving an element around after reloading a score to get an update, but only a system of the layout. This definitely needs some "tender lovin' care."
...in 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.
In reply to ...in a large score, the… by mike320
Third of a year later there seems to be no update about this, although we did get telemetry and a few other upgrades in 3.4.x and are onto 3.5. Any news about this major bug?
I haven't had time to look and don't expect to any time soon. If someone else (including you) wants to have a crack at it, be my guest. To me it's not that major, though, it's easily worked around and only seems to affect a small number of scores. Personally I'd be fine with someone implementing two layouts on load, that's probably a one-line change.
You mention in a later response some unspecified behavior that you think is more serious, but if that's what you mean, probably you should submit a separate issue with score and steps to reproduce.
In reply to I haven't had time to look… by Marc Sabatella
Thanks for taking the time to respond. I also haven't looked into the issue code-wise.
It seems that the problem I’m encountering is related to this post. Here are details of my experience.
The harpsichord works of J.-H. Fiocco use an ornament sign that looks like a trill with a short slur from the previous note, indicating a trill with a lengthened first beat (tremblement lié). See attchment for example. In MuseScore I create this by adding the trill sign as a text element, then adding a slur on the previous note, turning off automatic placement for the slur (otherwise it goes under the trill sign), and finally shortening the slur since it is usually too long.
I have found that these slurs are not being saved properly, or are being modified when the file is reopened. This morning I fixed over a dozen that were correct on the copy I printed out a few days ago. In other words, I entered the text, saved, printed and proofread it, then today I noticed that many of the slurs were wrong on screen; the automatic placement for each of them was turned back on, putting the slur under the trill and in its original length. I use MuseScore 3.4.1 on Windows 10.
This has happened many times since I began work on Fiocco’s suites, and with two totally separate files. Not every slur+trill gets undone; I would guess about half of them do. I have tried to figure out under what circumstances this happens but have not been able to do so.
It’s a nuisance to redo work already done, but even more important is this: once I have printed and proofread a section, I assume that it’s finished. Having errors creep in that I may not notice later is NOT a good thing.
I realize that it’s hard to track down intermittent errors. I wonder if it has to do with automatic placement somehow. I am willing to share one of the scores, but I’m not sure how much help it will be since the problem happens only sometimes.
In reply to It seems that the problem I… by redux02
@Redux02: Yeah, an unfortunate bug as of yet. In the meantime, one option might be to have a slur be linked to a grace note with disabled playback, then customize its spacing as needed. Afterwards, you can easily "copy and paste" one that has been done well for others. Probably sounds like a nuisance, but it might be worth it in the long run, especially if you have more to be inputting.
For example, depending on how the original you're copying has it, something like
![a.png]( "a.png")
might work well, where the whole note is actually an acciaccatura which has been altered to be a whole note ['w'] to ease making it invisible afterwards. Extend horizontal offset to the left a bit if it's too short or long. This might solve your unstable formatting.
In reply to It seems that the problem I… by redux02
Are these corrected when you force a layout? E.g. by moving a note up and down again?
If these slur are at the right position again after such an action?
see https://github.com/musescore/MuseScore/pull/5797
https://github.com/musescore/MuseScore/pull/5797
This PR solves the original issue and used the suggestion given by Marc Sabatella (https://musescore.org/en/comment/reply/node/297501/comment_no_subject/9…).
It might also solve the second issue (https://musescore.org/en/comment/reply/node/297501/comment_no_subject/9…) but for me it was not that clear where to find an example which went wrong and what was expected.
In reply to @Redux02: Yeah, an… by worldwideweary
@worldwideweary: Thanks for the suggestion -- I will try this. There are a couple hundred of these ornaments in Fiocco's suites, so I've got to figure out some way to deal with this before.
@njvdberg: No, making other changes such as a note value does not fix the improper slurs.
In reply to https://github.com/musescore… by njvdberg
@njvdberg: To see examples of the problem, in the MuseScore file I attached above, go to the Gigue on the 5th page (page number shown as 40 in the footer). In measures 7, 9, 11, 15 and 16 in the right hand you will see trills with slurs from the previous notes. The slur should be above the trill and slightly shorter (the exact amount I shortened the slurs by varies depending on the layout). See the PNG file I posted for how they should look.
A similar issue with String Numbers was found: #302316: String number under slur interferes with slur.. A PR for is issue is almost ready and will replace this issue.
@redux02, sorry, I can't still see what you mean. To start with, there is not page 40, I see only 35 pages. Next I'm a little worried about the used fonts, even in the first measure I got already an unknown character:
![img1.png]( "img1.png")
I don't think is what is meant :-(.
For the example, can you create a new score and just copy the measure with in example into this score and attach it?
See https://github.com/musescore/MuseScore/pull/5812, replacing the previous PR5797
Thank you for continuing to work on this issue! The page numbering begins with 36, so the 5th page is shown as 40 in the footer. I have a custom font for the special ornaments and other symbols in French Baroque harpsichord music. Because these are not in MuseScore, I have to create the ornaments as staff text rather than using the Ornaments section of MuseScore's palette.
I should add that the ornaments are placed in the the Private Use Area of the font since they are not standardized. Up to date software should be able to handle any Unicode character, including PUA values, but there is some chance that this could be part of the problem. I have not tried creating staff text using characters such as the regular Latin letters, adding slurs, and seeing if the layout is unstable.
I have used this font with several scores and had no issues except involving slurs, so I am pretty sure it's OK. I will share the font if you wish.
Fixed in branch master, commit 2498950a2c
_Fix #297482 - Score layout shifts when saved with fingering on acciaccatura
Solves the shift of the fingering on the grace note, and therefor the shift of the line above the fingering.
The root cause was StemSlash. Shapes for the StemSlash are created during the layout of the
beams of the grace notes and the layout of these beams is with the layout of the complete Chord
to which the grace notes belong. As a result, the shapes of StemSlash are added to the skyline
after the layout of the Fingering so the layout of the Fingering was based of the layout of the
Stem only.
After a re-layout the StemSlash is included in the skyline so the re-layout will move
the Fingering and, in this case, also the line.
The solution was a extra layout of the StemSlash in Score::layoutChords3() so it StemSlash is
included in the skyline in time.
Although this issue is vert similar as #302316 and fix #297501, the root cause is
different._
Is this really fixed, though? Or did this get crossed with #297482: Score layout shifts when saved etc.? As far as I can tell the fix for this issue is PR https://github.com/musescore/MuseScore/pull/5812 which isn't merged yet. I think this accidentally got closed on the merge of PR https://github.com/musescore/MuseScore/pull/5822, which mentioned this issue in a commit message but didn't actually mean to suggest it was fixed.
FWIW, I have tested the PR for this issue (5812) and I do think it's good, and I think it also fixes #302966: Slurs: manual adjustments lost when the score is reloaded (at least, the steps given no longer make any sense once this fix is applied).
So we're waiting on https://github.com/musescore/MuseScore/pull/5812
This message refers to PR5822 but doesn't solve this issue, that's PR5812.
However, this issue in fact report 2 issues, the original shift of slurs after a reload. Later another issue was added. I look similar, it might be similar and even solved with PR5812. but I'm still not able to reproduce it (or even see it).
Fixed in branch master, commit 8f1d51af2a
_fix #302316, fix #297501 - slurs and fingering
When a score, containing a fingering under a slur is loaded, the slur crosses the fingering.
Only after a relayout the slur is drawn higher so it won't intersect the fingering (issue
The root cause of this issue is the shapes of the fingering elements where not available
when the bezier of the slur is calculated. The fingering shapes are calculated after the
slur bezier is calculated. This explains why a relayout will solve the issue, then the
fingering shapes are available. The shapes are calculated during the calculation of the
note shapes but there was no call the fingering layout() method, making the bbox of
the fingering shape invalid and therefor it is not added.
This issue is solved by, in Score::layoutSystemElements(), calling the
Segment::createShapes() when layouting the fingering elements.
This solution also solves #302316 which also requires a relayout after a String Fingering
is added to note under a slur._
Fixed in branch master, commit f214cd1535
_Merge pull request #5812 from njvdberg/issue-302316-slur-shift
fix #302316, fix #297501 - slurs and fingering_
Automatically closed -- issue fixed for 2 weeks with no activity.