Position shift of slur on small staff when reload score
Reported version
3.3
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Sorry, I don't know English well, and I don’t know where to send the letter. Sometimes I need to correct the position of slurs. Here is a description of my actions:
1) Create score with small staff and notes slurred with autoplacement (slur_shift_1.png).
2) Deactivate autoplacement of slur and manually adjust the position of slur (slur_shift_2.png).
3) Close score and open it again: slur position shifted (slur_shift_3.png).
There is a bug, or am I doing something wrong?
Thanks!
| Attachment | Size |
|---|---|
| slur_shift_1-1.png | 23.83 KB |
| slur_shift_2-1.png | 23.62 KB |
| slur_shift_3-1.png | 23.92 KB |
Fix version
3.4.0
Comments
In reply to (No subject) by Jojo-Schmitz
Hello!
Sorry, maybe I don’t understand what “Frequency - Once” refers to. But the described problem often arises for me. More precisely, whenever a similar notation is used. And on another computer with a different OS and previous version MuseScore 3, too.
I forgot to write in step 3) to save the score before closing, but this is implied. And further. After step 3), if you increase the size of the staff to 100%, the slur shift disappears. But I need a small staff. Maybe I'm wrong, but it seems that every time when you open the score, the program incorrectly places slurs, whose position is set manually on the reduced staffs. And if you save the score every time, the next time you open the score, the shift increases. You can manually correct the position of slurs, but after reload score, the slurs on the reduced staffs will move. For me, the inability to save settings for slurs is a problem and I really hope that there is a solution. Please tell me if any further explanation or examples are needed.
Many thanks!
See https://musescore.org/en/handbook/developers-handbook/getting-started/h…
If it happens to you often or always, that is Reproducability. Frequency is the number of similar reports
Dear Joachim, I have received your letter. Probably you correctly specified the name of the topic. I'm not sure I correctly formulated the problem. There are other reports of slurs being in the wrong position, for example # 297501 "Layout shift of slur after reload".
I am trying to read the developer's guide. Thank you very much for your reply!
#297501: Layout shift of slur after reload? So maybe your's is a duplicate of that, unless it affects small staves only for you, which is one of the speps you mentioned, those are not mentioned in that other issue
In any event, I can't reproduce the problem (using the current 3.3.4 release). In order to investigate, we would need you to attach your actual score, not just pictures. Also be sure you have the current version, certainly there were other bugs involving small staves fixed a few releases ago.
Actually, I take it back, I can reproduce it if I keep trying. There is only a small shift for each time, nothing like what is shown, but after several successive saves and reloads, I can see that it has moved.
https://github.com/musescore/MuseScore/pull/5538
I fixed the same basic issue for other lines a few months ago, but slurs got left out.
In reply to https://github.com/musescore… by Marc Sabatella
Dear Marc!
I attach test scores corresponding to previously attached images. I intentionally made them very simple. But maybe I'm doing something wrong, then please say what.
OS: Debian GNU / Linux 8 (jessie), Arch .: x86_64, MuseScore version (64-bit): 3.3.4., Revision: 7684abe. I am using AppImage.
Forgive my misunderstanding. If you can’t reproduce the problem, please tell me what should I do if my slurs behave as described above. Although if the program can behave so differently, it probably should attract attention. The site says "Suitable for all Linux distributions." And if you can still reproduce, what fix and how to apply to fix the problem?
Many thanks!
Sorry if I was unclear. In my first response I said I couldn't reproduce the problem, in the second I said I was wrong, now I can reproduce it, in the third response I posted my proposed fix, which will hopefully be part of the next update :-)
Thanks!
Is it possible in a future release in the Inspector to make a separate offset for the extreme points of the slurs? Then it will be possible, not by eye, to accurately record the league's slope.
It's possible that would be added someday, feel free to submit that request separately as a "Suggestion".
Note it's already possible to be as precise as you want, just use Ctrl+Up/Down/Left/Right to move any handle in exactly 1sp increments, or without Ctrl to move in 0.1sp increments.
Fixed in branch master, commit 29a9ee0970
_fix #298564: shift of manually adjusted slur on small staff
Resolves: https://musescore.org/en/node/298564
We currently write the offsets for slur grips
scaled according to the staff, but we read them
scaled according to the score. That's because
on read, the slur hasn't been added yet, so the track is not set.
I fixed the exact same issue for other lines in
https://github.com/musescore/MuseScore/commit/812a2811b9754e8c327e491c7…
but slurs have their own own read/write and I neglected
to make the corresponding change for them.
This fixes the issue by explicitly scaling according to score.
Note there are other reasons why this makes sense,
see other comments in https://github.com/musescore/MuseScore/pull/4827
for more information on the scaling of offsets and other properties._
Fixed in branch master, commit 13649eb47d
_Merge pull request #5538 from MarcSabatella/298564-slur-shift
fix #298564: shift of manually adjusted slur on small staff_
Automatically closed -- issue fixed for 2 weeks with no activity.