Cross-page glissandos don't display normally

• May 11, 2019 - 13:40
Reported version
3.x-dev
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

See screenshot ->
批注 2019-05-11 204013.png


Comments

Well I adjusted the page settings so they're on the same page now. But re-making the bugged glissandos is actually easy -- look for violas in measures 102 to 103. The notes are not supposed to be there -- they're just a demonstration of the bug.

Attachment Size
Promenade - I. The Gnome.mscz 52.72 KB
Status needs info active

The main thing to make sure you have in the setup is hidden staves so the measures on one page do not line up with the measures on the next page. The glissando lines are then drawn so they will point at where the notes are on the other page. So if you have measure 1 with a C4 and measure 2 with a E4, but there are more staves visible on the page with measure 2 the glissando will actually point down on page one, even though the next note is higher. That is what is being shown in the original picture.

There is not hidden staves. In fact, there is a lot, in upper staves, of elements (staff text, slurs) which increase the distance between staves and so impact the position of the glissando. For example, delete all slurs and "arco", and other, in the previous staff, and it's solved or grantly improved. And so on with other.
I don't know if this can be considered as a bug. Not sure. As said by the user, change the layout to avoid the glissando to be in an uncomfortable position, "I adjusted the page settings so they're on the same page now", and the problem is gone.

See (an example, with slur)

Video_2019-05-11_171947.gif

Hidden staves or staves spread out due to automatic placement have the same effect. The important thing is that the staves in the two measures not be at the same point on the page. I was giving a scenario I had noticed before.

Frequency Once Few

It should be a bug because it makes the score look wrong. Down-pitch glissando shouldn't be going graphically upward by any means.

In reply to by __Zwischen__

I think it doesn't happen only because of auto-placement. If the glissando takes place between systems, as long as the same staves in different systems and the notes connected by a glissando have an opposite vertical-placement relation, the glissando will always have the wrong direction.

This actually happened in version 2 also, so there is no way it's related to auto placement. MuseScore doesn't handle a glissando that crosses a system break correctly. It always draws it in the direction that the other end is in relationship to the start on the printed sheet. If the next system is on the next page above the current note, the glissando is drawn upward, if the next system is anywhere below it, the glissando is drawn downward. The angle of the line is determined by how far above or below the next note is compared to the current note.

One thing MuseScore does not do as far as I can tell is calculate where the next note would be if it were on the same system (which is what we expect) and draw the glissando in that direction. It would need to also remember this calculation so it would draw the glissando at the correct angle at the other end of the line rather than at the current extreme angle it uses pointing at the physical location of the start point.

I really think the Severity of this should be at least Major if not Critical because any attempts to "fix" this are discarded upon save and reload unless someone knows how to prevent this.