Fingering affects layout with autoplace disabled

• May 29, 2019 - 08:58
Reported version
3.1
Priority
P1 - High
Type
Performance
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

As titled with attached score:
1. “Synthesiser” -> “Fluid” -> changing fonts, for e.g. deleting “MuseScore_General.sf3” and adding it again;
2. Click “Save to Score” -> close “Synthesiser”;
3. “Ctrl+S” to get captured:
Gap.JPG

Attachment Size
Nocturnes, Op.9 (Chopin, Frédéric) No.2 - Violin & Piano V3.mscz 222.51 KB

Comments

• Jun 1, 2019 - 02:12
Status needs info ⇒ active

Actually I see all sorts of weird effects in this score, by going to measure 34 and changing pitch of notes. It turns out to be about the fingerings of the form "1 ________________", which we are trying to allocate space for to avoid collision with the note. Depending on the exact position of things, the dashes either collide with a beam, or the next fingering, or they don't. And when they do, that's what is responsible for all the extra space. Probably that text shouldn't have been entered as a fingering but instead as a text line. I see automatic placement is disabled for them, so it shouldn't be affecting spacing even so, but apparently it sometimes does, so there must be a place where the check isn't working.

All of this is reason why the layout is likely to not work well no matter what - but it still doesn't explain why it shifts on save. That's probably related to #289946: Layout shift after load in score with fingering and the very long fingerings you have are just making this effect more pronounced.

Reply

• Jun 1, 2019 - 16:57

This “2 __________” is a violin standard fingering which instructs player to “press and hold” for the period indicated by the length of the line. This score wad edited and saved in version 3.0, it didn’t complain the space overlapping (collision), and when saved (manually or auto) again in version 3.1, it looks it’s checking it with new rules implemented.
overlapping.JPG
And after saving and reopening, it shows normally, until another “Save”, as mike320 found.
Version 3.1 and later versions should allow this fingering format.

Reply

• Jun 1, 2019 - 17:23

To be clear, we do allow this format, it's just as I said, it's not good to use the "Fingering" element specifically for it, because this element was not designed to work with extended lines like this. There are many reasons why you are better off using text lines instead, the most obvious being, then the line can size itself correctly automatically rather than depending on your entering the exact right number of underscores and constantly needing to adjust this as the layout changes. But also how autoplace works, fingerings are special in that they are designed to affect note spacing because normally that is what you want. Here, you don't, so you were forced to disable autoplace, which you shouldn't have had to do if you had used a text line instead.

Reply

• Jun 1, 2019 - 18:12

Thanks that’s true there are some advantages using text input. Years ago when I first time started using MuseScore 2. I compared these two choices of input this special fingering either as “Fingering” or “Text”, and found “Fingering” could meet all format requirements and made more sense than “Text”, simply because it is fingering and I got used to input "2 ____" as "Fingering". Time to consider change now?

Reply

• Jun 1, 2019 - 21:30

I think so, then you won't have to guess how many underscores you'll need and constantly look out for changes, nor will you need to disable autoplace to get it to work without affecting layout (and of course, until my PR gets mer.ged, even that doesn't help). But. it's up to you of course.

Reply

Fix version
3.2.0