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.
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.
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.
This issue is probably the same as the one I reported a while ago. https://musescore.org/en/node/288186
The problem arises when the auto-placement function increases staff distances.
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.
Comments
I cannot reproduce with glissandos here right now. Please attach the involved score (images don't help)
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.
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)
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.
It should be a bug because it makes the score look wrong. Down-pitch glissando shouldn't be going graphically upward by any means.
This issue is probably the same as the one I reported a while ago.
https://musescore.org/en/node/288186
The problem arises when the auto-placement function increases staff distances.
You mean #288186: Glissando across system is not drawn correctly when auto placement increases staff distances
Yes, this can be a problem.
There can also be collisions (look at the key signature on bar 3):
![Glissandi collision.png]()
Using MuseScore 3.2.3 - Mac 10.11.6.
In reply to This issue is probably the… 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.
Came up again in https://musescore.org/en/node/297700
Bump.
Duplicate of #198716: Glissandos across system breaks can point in wrong direction if there is a hidden staff.