Bad layout of straight chordlines ("slides")

Hi

Thanks for the report!

Could you list the version and operating system?

I should be able to get this.

Well, it seems to be some special case handling for these symbols in ChordLine::layout() to try to mimic Guitar Pro that is the problem, so I'll let someone else take a look.

BTW, it actually affects all the slide symbols, but differently, and it is wrong for standard staves as well. The slides out have too much space before them, and none of them line up vertically as they should on standard staves.

It's not just tablature, though - they are just as bad in standard staves.

Thanks for the report! I'll pick this up. This might well be due to trying overly-much to mimic Guitar Pro (that certainly usually requires special cases, some of which I think were usually sub-optimal), if it's going to cause issues I don't think we should try too hard to do that. Perhaps we can still do that though, I'll take a look.

I'm skeptical about this exclusive glissando type.

I could be wrong, but is it not this?: #7662: Ability to add a glissando to an unique note

What do you mean "skeptical" and "exclusive"? The symbols in question are actually quite generally useful - straight line versions of the scoop/fall/doit/plop symbols, still editable like those but only for length.

But I would say it is not worthwhile to try to emulate how Guitar Pro might happen to lay these out. There's really no reaosn I can see to special case them at all, except that apparently their attachment points ("pos", I guess) differs from other chordlines. Because I tried simply ripping out that special case code and things got even further off.

Aren't these symbols only a Guitar Pro workaround for the real thing (issue 7662)?

Not sure what you mean. The symbols in question here are much more generally useful than just for Guitar Pro import or just for the special unusual request in that other issue (single ended lines that actually include the word "gliss", which is highly non-standard and not what these lines do).

I'll still not suite sure what people are saying, but as someone who knows nothing about Guitar Pro and whatever special notations it might do, I can clearly articulate the ordinary musical purposes for three different element types we are discussing here:

1) Glissandi are lines that connect *two* notes. There is always a start and end note for a glissandi, specifying both a pitch and time for the gliss to start and end. You are supposed to use this symbol if and only you want to specify a specific start and ending time and pitch. These are not editable in any way; they are automatically positioned between the two notes (actually, chords). They can either be strsight or wavy. The word "gliss" (or any text you replace it with is automatically suppressed if the line is too short to display the text.

2) The curved chordlines attach to *one* note. They indicate a bend in which main notes is fixed in time and pitch, but the player is left to himself to decide on the amount and duration of the bend. The fall and doit appear after the note and indicate a bend after the note with the end point left unspecified in time and pitch; scoop and plop appear before the note and indicate before the note with the start point unspecified in time and pitch. These lines are editable like slurs - you have full control over the length and curvature of the line.

3) The straight chordlines are *exactly* like the curved ones, except they are forced to be straight (so editing is possible for length only, not curvature). They are basically just a stylistic choice. They *mean* exactly* the same as the curved lines they resemble; it's just that some poeple prefer to draw these straight versus curved, and having them available on the palette as lines that are forced to straight makes it possible to get this effect without needing to manually straighten out a curved line. As far as I am concerned, this could have just as easily been done as a checbox in Inspector.

Of course, I realize these symbols were only *added* becausde of Guitar Pro, but that doesn't mean they are only *useful* for Guitar Pro import. They had been requested long before. So whether or not Guitar Pro uses the straight chordline for some other purpose other than just a stylistic variation on the curved chordline is irrelevant to me. If they are to be on the palette in MuseScore and available to be placed on a score, they need to work as would be expected by a MuseScore user with no Guitar Pro experience.

So I'm fine with there being special case handling of these symbols when added during Guitar Pro import if that turns out to be useful. I just want to make sure they behave normally when added normally by a MuseScore user.

Chord lines are just objects with no real value (there is nothing for potential flexibility with regards to layout, or playback properties). It's an okay workaround, but not one for the long-term.

From what I see, the real solution is to implement issue 7662 and treat glissandi in GP files as such? In comparison to chord lines however, could we be missing anything?

????? Chordlines have no value? They have been an absolutely indispensible part of music notation for a century. I have no idea idea what you are talking about. What on earth do you mean "not one for the long-term"? It's a problem that needed solving, now it's solved. Layout works just fine and exactly as expected (except for this bug), and while there are no playback properties right now, they could of course be added some day.

The "one sided gliss with the word gliss displaying" in 7662 is a highly unusual thing that I am not sure I have more than once in professionally published music (I was originally guessing some version Rhapsody in Blue might notate the opening clarient passage this way, but it's actually a tegular two note gliss, not sure what I was thinking). Chordlines I see literally dozens of every day.

I would add that allowing *wavy* chordlines is a fine idea for an enhancement someday.

I didn't say they hadn't any value, but for uses like this and depending on the environment (viewed in the app, in which layout change is likely), they may not bend in the wind (i.e. they could end up inappropriately placed) because it is just a static object that doesn't know any other purpose.

Have you used these lines? I think you may be fundamentally misunderdtanding what they are, what they are for, and how they work. They are specifically designed so that they *do* layout in predictable ways, meaning they *do* survive layout changes meaningfully. That is, they do *exactly* what they are supposed to do, and everything that 7662 was intended to propsoe *except* the very specific and unusual use case of wanting the word "gliss" to appear, or allowing wavy lines (which could of course be implemented some day).

Sounds like it would be best for the implementation for this feature to be simpler than it currently is - trying to match Guitar Pro exactly in this case makes the layout code for chordlines way too complicated in my opinion. Given that, I don't really see why the layout code for fall/doit etc and slide out, in etc. should be all that different in the end.

For the remark concerning that it can be confusing whether we are looking at a glissando (operating on two notes) or a slide (operating on only one note) due to the spacing that's there, this shouldn't be a problem if the layout is done correctly (and ideally should be the same anyway between fall/doit and the slide counterparts).

I'm not entirely sure of the relation of this to issue to issue 7662, I don't automatically see a direct connection between this issue and that one; this issue is really about layout problems.

I certainly wouldn't mind hearing more about what the Guitar Pro emulation was trying to do, and if there is a way to make it do that on the import side as opposed to in the layout and drawing code, that is totally fine by me. Maybe we can find a solution that works for everyone, or at least for most cases.

BTW, I mentioned having tried to fix this by ripping out the special handling for these elementsin ChordLine::layout(), and said that made it worse. I now think that might just be because draw() also has some similar special handling and I would have needed to remove that either instead or in addition.

The curved chordlines attach to *one* note
That's wrong. curved or straight chordlines are attached to one *chord*. Thus the name, and thus issue #7662: Ability to add a glissando to an unique note.
Idem for glissando, they apply to chords and not note.

As far as I understand curved chordlines are mostly used for wind instruments, especially in jazz. By contruction, a chord is a single note for these instruments and so there is no problem.

However, the straight lines are mostly used for guitars, and then it becomes a problem since chordlines can't be added to single notes in MuseScore. On the other hand, I just tried TuxGuitar, and slides can be added to single note of a chord without problem. So we will have a problem when importing GP files for sure.

Regarding glissando, it seems parallel glissando is a thing. Currently it's not possible to do in MuseScore either since glissando are from chords to chords too.

Thanks for the clarification - yes, when I said a chordline attaches to one note, I really meant, one chord. My point was that unlike glissandi, they are only attached at one end. But like glissandi, they attach to the chord not the note, and this can indeed be a problem for both of these symbol types.

I'm hoping maybe at some point we can change how both chordlines and glissandi work, so they are attached to individual notes and not chords, without breaking existing scores. That would instantly solve most of these issues. Right now it appears we always lay out both of these elements relatve to the top note of the chord, so we could just assign it that way on read. Might not even be that big a change, although if/when we make it, we should also fix the implementation to allow for true cross-system glissandi, and that's perhaps a bigger change.

Anyhow, since we currently only support one glissando per chord, as you say, there is no way to make parallel glissando lines between two multi-note chords. However, since we do support multiple chordlines per chord, I can see there would be a temptation to try to use the straight versions of these as if they were glissandi so you could have one for each note of the chord. But since a) they are laid out relative to the chord, not the note, and b) they are only attached at one end, you'd probably need to do a lot of fiddling to get it to look right, and this would end up being "fragile" with respect to layout. Maybe this is what chenlung was thinking of? And maybe that's why is supposed to be happening in the Guitar Pro import?

But I'm more concerned right now with chordlines used "normally" - as lines intended to attached at only end (whether to note or chord). While the straight versions of these lines may have been introduced to allow Guitar Pro files to have something resembling parallel glissandi (that's still just a guess on my part), they are definitely used as a stylistic choice in wind music as well. It's especially common for long falls to use straight lines (well, sometimes wavy) rather than curved. So my concern in this issue is simply that straight lines behave reasonable when applied from the palette. I'm still all in favor of letting Guitar Pro import apply custom settings to the lines it creates so they lay out differently if that's useful.

BTW, I think another source of confusion is that #7662: Ability to add a glissando to an unique note can actually be seen as describing several different features requests. I have been focusing on the "single ended" aspect of it, because that's what the each of the glissandi in the sample file show and that's what the description of the issue seemed to focus on. So by "unique note", I have all along been interpreting that request as "please provide single-ended glissandi". Except for the failure to include the word "glissando", chordlines solve that feature request.

However, on closer inspection, I now notice that one of the glissandi in the file happens to also involve a two-note chord, with two parallel lines coming out of it. It's still single-ended, and thus it's really a chordline and note glissando at all. But maybe some have been interperting that feature request as if it were "allow one glissando *per note of the chord*". That's a totally unrelated thing as far as I can see, though. Allowing a glissando between pairs of *notes* as opposed between pairs of *chords* is important, but it is not what 7662 is about. Allowing glissandi between pairs of *notes* as opposed to between pairs of *chords* is a completely different feature request - it's this one #19155.

So if one was confusing 7662 with 19155, I can see why you'd think chordlines were not much a solution. They indeed don't solve 19155 at all. But they they *do* largely solve 7662.

Fixed in b68fcb9ca8

Automatically closed -- issue fixed for 2 weeks with no activity.