Small ties

for some reason, this bug has not been taken into account lately, but I believe it to be of incremental importance.
It still occurs even in Nightly 2370 as the screenshot shows.
It is extremely important that this gets fixed as soon as possible, because it's a h@ck of a pain to print out a fullscore and have tie not show up...... Especially in modern music where you have a considerable amount of tied notes.....
Please developers, when you have time, try to fix this.

oh, ok. I didn't know that critical was reserved for that.
Yes, I know the routine of a bug being considered as occurring also in the latest nightly, but we both now that it's something else if someone posts that it it really happens in the latest one as well.
I know about the workarounds, but I personally would rather wait until it is fixed.
Reason? too many ties to edit..........

Out of curiosity, do the ties- that you need to edit in these situations- do they playback properly, also? I just posted a bug about that issue, also.

yes, they play back properly, THANK GOD!!!
they just don't show right on the score

ties are definitively too small. Would it be possible to fix this bug?

I am still seeing this problem, over 2.5 years since it was raised! Is there any plan to address it? It seems like a pretty major problem to me; as other users have said, manually correcting this can take a while.

It might become fixed for 2.0 - coming later this (or early next) year.

I noticed this issue when using grace notes to illustrate flams for snare drum. Manually editing the tie itself to appear farther away from the note heads fixed the issue, but it was one at a time... really painstaking.

Some type of Style > Edit General Style > option for how close the ties appear to the note heads or related stems would yield a customizable solution that could be saved in the template.

Select the first tie;
Click on the first, select all;
Hold down Ctrl and drag with the mouse.

Seems from your screenshot SIbelius actually does both? Certainly the half notes are much more widely spaced in that particular example, although of course that could be for any number of reasons, like fewer measures in the system, different overall spacing settings.

I have to imagine Elaine Gould expresses an opinion here in "Behind Bars"?

My gut says Option 2 is the better solution for us. Changing the default attachment point for ties may well have a ripple effect that might force us to revisit other aspects of layout. Simply adding a minimum amount of space between tied notes seems less invasive to me. Of course, I'd prefer it be a Style setting as in Finale, but I'd settle for a hard-coded default.

Could you possibly show a more relevant / apples-to-apples comparison screenshot between Musescore and Sibelius, then? Something maybe involving eighth nites in similarly tight spacing? The example with the half notes is not very helpful because half notes aren't a problem in the first place, and also because for whatever reason, the spacing is so vastly different between the Musescore and Sibelius examples. As far as I can tell from the screenshot, it's the difference in note spacing, not anything having to do with attachment points, that makes the ties more viaible in the Sibelius example.

Thanks for that, very informative! My initial reaction is to do a 180. I don't like the looks of the Finale example (although I recognize it's not common to have ties within a beamed group), and I think the Sibelius method seems quite effective with similar note spacing (although it is still a bit looser than MuseScore, which I think does help). Just as significantly as how it looks, perhaps, I also now think the "ripple effect" on layout would actually be worse with the Finale method.

All that said, I will acknowledge 2.0 already looks a lot better than 1.3. For 1.3, the ties didn't overlap the noteheads at all. For 2.0, it appears to overlap about 20% the width of the notehead. Sibelius seems to be doing more like 30-40%.

I decided to look at the code to see what might be involved. It was trivial to up the overlap value (default is 15%), so I tried increasing that to 35% first. This works like a charm and looks good. But that only works cleanly for single notes (as opposed to multi-note chords), and only in cases where tie doesn't interfere with the stem (which can happen tying an upstem note to a downstem note, or if the tie is flipped). In these cases, MuseScore shortens the tie to avoid stems or other noteheads. And it seems in those cases, adding extra space would be needed.

I reinstalled the Sibelius 7 so I could play with it myself to see how they handle the various different cases. What I see happening is:

1) For single notes, the ties always overlap by around 30-40% by default - even if this causes a tie to cross a stem (as can happen tying an upstem note to a downstem note).

2) If you create a tie between single notes then flip the tie, the tie shrinks to avoid the stems, even if this makes the tie unreadably tiny.

3) For single notes that are close together, there is *also* a small amount of extra space added before the second note to enforce a certain minimum tie size - it's subtle, but you can clearly see it happen if you add ties between existing sixteenths. I am not convinced this is necessary.

4) When tying between multi-note chords, then the ties don't overlap the notes at all.

5) if the tied chords are close together, there is also extra space added before the second chord to enforce a minimum tie size - and it seems in this case, Sibelius is willing to add a surprisingly large amount of extra space (around 1sp extra space added between sixteenth note chords). In this case, because the ties cannot overlap the notes, some additional space is clearly needed, but Sibelius goes too far.

6) I'd also observe that Sibelius does a decent, but by no means great, job of positioning ties vertically to avoid overlapping staff lines too much.

From what I can see in examples on the web site, it appears LilyPond uses a variable amount of overlap with the noteheads. Even so, there appear to be a significant number of cases where manual adjustment is necessary.

Bottom line for me: getting perfect results in all cases is not reasonable to expect, but we can do better. I think we can get a ton of benefit with two simple changes (well, one trivial, and one presumably not difficult):

1) Change the default overlap from 15% to 35% (or whatever).
2) Add space as necessary to enforce a minimum tie length in the cases where the tie is otherwise being shortened to avoid stems or other noteheads.

It's nice that these changes improve the display and readability of ties. How difficult would it be to give the end user an input box to adjust those parameters to our own personal application?

Setting parameters like how far an anchor point is located from the notehead, how much slack the arch in the tie gets between the anchor points, thickness of the line drawn, how much additional space is allocated between notes that are tied, force stems to same direction when tied ... All those things would allow users to customize these for their particular application.

Now... allowing for input boxes that update the code, that's likely 10 or 20x the job of changing the code parameter from 15 to 35%. It might be worth it if the one fix doesn't address all the issues. If users can set the parameters themselves, what is left to complain about? ;-D

If users can set the parameters themselves, what is left to complain about? ;-D
That's the interface is too complicated to operate!

Nah, set the defaults and add a button next to a general tie or slur distance for 'advanced options' that deal with the intricacies...

To be clear, the user can already customize the appearance of any particular tie - double click and edit handles (except this currently crashes - see #23399: Moving either end anchor of tie causes crash). You can also manually add padding between notes using the Inspector (segment / extra leading space). So the only question would be whether to add a way to customize the *defaults*. If that were to be done, the obvious place would be in Style / General / Slurs/Ties. This currently only provides settings for thickness - something you can't otherwise override, so that one arguably "needs" to be there more than the settings we are talking about.

What we'd be talking about would be adding one or more boxes to that same dialog. Potentially, one for the attachment point in the default case, one for attachment point in the "shortened" case (to avoid other noteheads in chords or to avoid stems when the notes or ties are flipped), and one for the minimum tie length. The first two of these seem like overkill to me, but I could see wanting to have a setting for the third. This seems quite in keeping with other settings in Style / General.

On the other hand, making this customizable seems nowhere near as important as just making it work.

Changing the attachment point is trivial, as I mentioned. Adding extra space to ensure a minimum tie length might be simple also, but requires more familiarity with the layout algorithms than I have. I wouldn't be surprised to find out it's trickier than I'd have hoped.

Interesting article regarding ties in LilyPond:

http://lilypondblog.org/2013/07/lilypond-tie-crusade/

I've got a fix coded up and plan to submit a PR soon; I just need to do some more tweaking and testing. Here is how I have implemented it so far:

- For "normal" ties (tie overlapping noteheads), I simply increase the amount of overlap from 15% to 35%, which seems about how Sibelius and LilyPond do it. Gould actually recommends attaching to the center of the notehead, but this seems extreme to me.

- For "shortened" ties (tie inside noteheads), I ensure a minimum amount of space between the two notes before the second note. That amount of space is currently hardcoded to 1.4sp (half that if the tie overlaps one of the two notes).

It would of course be possible to make these numbers configurable parameters, but that seems like overkill to me. I'd rather just get it "right".

Here is an image showing three ties (one is practically invisible) before my change:

And here it is after:

My sense is, #2 here probably got a little too much space (although the same amount of space looks great on eighth notes). And by moving the ties further over the notehead for #3, now it touches the notehead, which isn't great either. So I'm still tweaking. Feedback welcome!

Here's my branch if someone wants to check the code:

https://github.com/MarcSabatella/MuseScore/compare/2316-small-ties?expa…

It's actually a smaller change than it looks - part of it was just factoring out the calculation of tie direction from Tie::layout to a new function, so I could call it during chord layout.

After some tweaking, a subtler but still readable result:

I realized I needed to account for chords with seconds - ties are already extended so we don't need to allocate extra space. This proved tricky to detect and handle correctly, but I am happy now:

I should emphasize that my change only affect notes that are so close together that ties are shorter than about 1sp. Extra space is allocated only in the case of tied chords or stem-side ties. And you can still manually increase or decrease space between notes normally, and ties adjust.

Marc's examples seem okay, except for tie-after-2.

The tie positioning for the E notes looks wrong - they don't distinguish themselves from the stave lines.

Page 61 of 'Behind Bars' touches on this. Perhaps more relevant to this issue: "Ties are generally confined within one stave-space when they are very short, and when they must be flattened to avoid another part:"

I propose that ties with a height less than a stave space appear somewhere (?) between stave lines.

(The image may have to be clicked on to see it)

It might not always be the case if the notes are on ledger lines, though?

This might be helpful?

Yes, the vertical position and the arc of ties still leaves something to be desired, I would agree. However, that may have more an impact on articulations and other markings and I'd rather not mess with it right now. To be clear, the issue you identify is not new; it shows up the same way in 1.3 and in 2.0 before my changes; just potentially in different specific situations.

Anyhow, now that I've got the basic algorithm working, I've also gone ahead and parameterized things so that while the default attachment points remain fixed (subject to manual adjustment of course), there is one new style parameter: "Minimum tie length". This adds space between notes as needed to ensure ties are at least that long. It applies to both shortened and normal (overlapping the notehead) ties, although I chose a default value such that normal ties are not actually affected - they are already usually long enough with my change in attachment point. But if you choose a minimum length of, say, 2.0sp, you'll see space added for both normal and shortened ties.

One reason I went ahead and did this is to possibly better handle 1.3 scores. I'm sensitive to the fact that other layout changes already result in scores sometimes taking more space than before, and this change could continue that trend. But parameterizing the minimum tie length gives us the ability to potentially set this smaller for 1.3 scores.

More images and a PR hopefully coming soon.

https://github.com/musescore/MuseScore/pull/719

Here is how various ties look with "Minimum tie length" set to 1sp, which is what I made the default for now:

Here is the same example after bumping "MInimum tie length" to 2sp, just so you can see that ties do scale, except for the ones that are already longer than this minimum:

For now, I have set the default 1.3 scores to 0.0sp, which gives maximum compatibility but misses an opportunity to improve layout.

Fixed in adee450f8a

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

Makes me a little sad to reopen this since it was one of my first contributions to MuseScore layout, but the approach I used no longer works with the "new" layout algorithm. Maybe just as well, as it was kind of "hacky"; hopefully there is a way to get the job done more elegantly using shapes. I realize I could have opened a new issue, but there is some good analysis here and lots of examples to reference, so I figure we might as well keep it here.

Now, I'm no longer all that familiar with the layout code, so I would love it if someone else could step in and take a fresh look at this. Then I can also look at #188461: Bad tie lengths on mirrored end notes.

Updating according to my understanding of the categories. This is a very serious regression in layout compared to MuseScore 2. "Layout" is no longer a choice for "type".

It remains the case that I don't have great insight into the best way to fix this for MuseScore 3. The idea is we need to add enough space between notes to allow the full tie to display. The complication is that depending on number of notes in the chords involved and their stem direction, ties can be attached differently, so it's hard to get a good handle on what the length of a tie will actually be until later in the layout process than we'd like. At least that was the case when I implemented my two-pass solution for 2.0 originally.

One idea that might work in only a single pass:

When calculating the shape for a note, look at whether it has ties in or out. Based on the number of notes in the chord for that note and the stem direction, that should let us know how much the tie will overlap the notehead. We then create a box for one-half the minimum tie length specified in the style (and some nominal height), overlap this with the notehead appropriately, and add this to the shape for the note. So each note is responsible for half the length of any ties going in or out.

Fixed in branch master, commit ba21d03c75

fix #2316 small ties; increase minimum note distance if there are ties

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