Glissando incorrectly presented over line break

• Dec 13, 2009 - 15:45
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

When there is a glissando that occurs across a line break, instead of behaving like a slur and splitting up nicely, it will be naughty and jump to the next line and extend to the infinities. This is only related to the display and does not corrupt the gilss, as it behaves again when the line break is adjusted so that the two measures are juxtaposed.

One idea that would temporarily solve this problem (and would be very useful otherwise) is an option in the "breaks and spacers" palette that binds two measures together, so either both of the measures must jump to the next line, or they both must stay on the same line. Maybe this would be easier? (It can't be good notation practice to put them on separate lines anyway.)

Comments

• Dec 13, 2009 - 16:45

Confirmed using r. 2451 nightly, Windows XP

Glissandos across line breaks are normal. Your first suggestion was better: MuseScore should make them split across the line break similar to slurs. Attached is a screenshot of a glissando across a line break in Finale.

Attachment Size
glissando-finale.png 4.17 KB

Reply

• Nov 27, 2010 - 18:26

eranmagen, when this issue is resolved the status will change from "active" to "fixed" and eventually to "closed". As you can see it is still "active" at the moment.

Reply

• Feb 24, 2011 - 15:42

I can't even get gliss to work at all! Though where I want it is over a measure break. ??? I have version 0.9.6.3. I've tried dragging the different gliss symbols from the palette to either of the two notes, choosing either of the two notes and double clicking.... zilch. How is this supposed to work?

Reply

• Aug 17, 2011 - 20:37
Status (old) postponed ⇒ active

Hi,

I use version 1.1 and have this problem too. I have found the only solution is to make sure both measures are on the same line. This often messes up my lay-out, and sometimes it's even virtually impossible, as in this piece with a lot of glissando's between multiple measures:

http://musescore.com/score/23304

Good luck fixing this. I also believe it should be able to have the glissando split, like with a slur.

Reply

• Dec 20, 2012 - 22:04
Title Gliss over line break ⇒ Glissando incorrectly presented over line break

Is Finale's handling confirmed to be the correct way?

Are there rules on this?

Reply

• Jan 3, 2013 - 03:20

Page 142 of Elaine Gould's 'Behind Bars' explains that over a system break: "Reflect the correct interval of a glissando in the gradient of the line".

This doesn't reflect the example in #13 - it maybe different if there's missing rests and/or a wavy glissando line? Does anyone know of other explanations?

Reply

• Jun 4, 2014 - 16:44

This bug is over four years old now, and it is still very annoying. I am currently trying to get rid of glissando lines which have been broken when I copied a large amount of measures, and as these broken glissandos can not even be selected, removing them is quite hard.

Reply

• Jun 4, 2014 - 17:13

Selecting the gliss is possible if you do something to change the layout so that the gliss no longer crosses a system break. Or, in the development builds, switching to Continuous View, although even then, it seems you currently need to do something (even just Ctrl+A) to force a relayout before these broken glissandi appear. This will at least allow you to remove glissandi.

The bad news is this is not a simple bug to fix. Glissandi basically need to be re-implemented to allow them to span systems by drawing the gliss in multiple segments, much as is done for ties, slurs, and other elements on the "lines" palette. The good news is that at least we know it is possible.

BTW, I understand this is being considered for 2.0 but is somewhat of a long shot. This does strike me as the sort of thing that could be worth doing sooner rather than later for compatibility reasons. That is, the re-implementation might require a file format change, meaning that if we wait for 2.1, that may mean 2.1 scores containing glissandi won't open in 2.0. Although I guess this is not a given? And I know Miwarre has a lighter-weight implementation in mind based on the figured bass code rather than the full Spanner code.

Anyhow, if we *don't* actually do this for 2.0, I would propose we investigate a (hopefully cheap) partial fix where we don't actually draw a full glissando line on a chord at the end of a system, but instead draw a simple glyph. Actually, since glissandi are apparently attached internally to the target note and not to the starting note, perhaps we draw the glyph going into the target.

I think I could probably pull off this cheap/partial fix myself, but I won't bother if there is any chance of it being fixed for real in 2.0.

Reply

• Jun 4, 2014 - 18:47

FWIW, here is a cheap partial (*very* partial) fix. Add this code to Glissando::layout() right after we initialize sp1 and sp2. All it does it reset the start point for drawing the gliss to 6sp in front of the second note:

      // HACK: cheap partial fix for cross-system glissandi
      // draw line into target note only
      Segment* s2 = chord->segment();
      if (s2->measure() == s2->system()->firstMeasure())
            cp1.rx() = cp2.x() - 6.0 * _spatium;

The gliss length of 6sp was chosen to be clearly visible but not interfere too much with a starting clef, key, or time signature. I tried allocating extra space in Chord::layoutPitched() also, but it seems maybe systems are not laid out yet at that point, and I didn't think it was worth working on this further.

The result with the above change is that we see no gliss going out of the first note at the end of one system, but we do at least see the gliss going into the second note at the start of the second system, and it is positioned reasonably well and is selectable. Realistically, this is still no good at all of course, but at least it doesn't look as completely ridiculous as what we do now. I say, *if* we don't fix this for real in 2.0, we should add this code.

Reply