slurs—thin to fat snap!?

• Sep 23, 2014 - 15:51

V2.0 beta here...

I have notice that a lot of the shorter (in terms of duration) slurs appear too thin. The long ones look fine.

Check out this animated screen-grab...

2014-09-23_16-44-28.gif

You see the way the thickness of the slur sort of "snaps" between thin and thick as I resize? Is that the intended behavior? There is no way for me to thicken up these short slurs, as you can see...

2014-09-23_16-49-44.gif

Any ideas? Is this a bug or a "feature" ;)

Attachment Size
2014-09-23_16-44-28.gif 739.63 KB
2014-09-23_16-49-44.gif 493.77 KB

Comments

Can someone from the dev team tell me...

...is a tie and a slur calculated differently? I ask, because here's a slur and a tie side by side, with the same control points...

slur-vs-tie4.png

...as you see, the tie is thicker. Is we make it longer...

slur-vs-tie5.png

...then they become the same thickness. So, it seems like somebody somewhere has decided that a short-ish slur should be thinner...? If so, it would be REALLY nice if we could somehow disable that functionality.

Attachment Size
slur-vs-tie4.png 26 KB
slur-vs-tie5.png 30.79 KB

In reply to by douglas81

I can't think of a good reason for a tie to be thicker than a slur at the same length. In fact, I'm quite surprised there is any difference at all; they share much of the same layout code. File an issue in the tracker with a sample score demonstrating the issue, and I'll take a look. I worked on many aspects of the layout code for 2.0, but thickness of ties/slurs was not something I changed.

EDIT: looked at the slur code, and while much of it is highly mathematical will lots of Bezier curve calculations involving trigonometric and logarithmic function on pretty cryptic looking combinations of figures, it turns out there is one very clear place where the thickness of of the slur is cut if some particular calculation does not meet some particular threshold. It's mostly Greek to me, but I can verify that removing those two lines makes slurs thickness independent of length. So the good news is, it would easy to fix this. What I don't know is if there is a reason it is as it is. Maybe the thinning was only supposed to kick in at shorter lengths. But even so, no idea why there is no corresponding adjustment for ties.

In reply to by Marc Sabatella

Yeah, it's a bizarre default behavior, right?

Perhaps it was a decision made early on by the developers. It seems to me that if the slur is under a beat in length, it is thinner. I have found some old G.Henle Verlag piano editions where both the the slurs and ties have a noticeably thinner mid-point for short (i.e. less than a beat) ties. However, and this is crucial, I can't find a single example in any editions where there is a noticeable difference in character or thickness between ties and slurs.

To put it another way... in any respected print edition of anything I have looked at, slurs and ties are treated as equals, with the exception perhaps of the shape and placement, but we are able to adjust that without problem. So, even if slurs and ties are thinner when they are less than a beat, the rule applies equally to both ties and slurs.

Good news that removing a couple of lines of code fixes the issue!

In reply to by [DELETED] 5

From scanning that, I think that's changing the shoulder angle, but it's not changing the thickness. Looks like down around here we start dealing with thickness...
https://github.com/musescore/MuseScore/blame/bdbaf5a27e8b45f1f193303fd3…

I think it is correct that slurs and ties are dealt with differently. That makes sense because they "attach" or "point" to different parts of the notehead.

My guess is that at some point after the tie calculations have moved to their own code, modifications have been made to it, but not to the slurs. Or, perhaps, the code is not speaking to each other as expected.

In reply to by [DELETED] 5

Actually, I meant these two:

https://github.com/musescore/MuseScore/blame/bdbaf5a27e8b45f1f193303fd3…

These lines were also there from initial GitHub commit, but I hadn't looked into sourceforge to find the older history. The comparison here is especially odd - dividing by spatium and them comparing against spatium? Normally, it would be one or the other. Otherwise you are basically comparing something against spatium squared, which is a bizarre unit. But I don't understand the math here at all.

The spot you mention might be relevant too. I suspect it's more about the depth of the curve though.

Anyhow, that's good information about the code diverging. Whatever this tinning code is meant to do, changes are it would have made at least as much sense for ties. But it should only kick in much for much shorter slurs / ties. Replacing skipping the division by spatium might do that. but again, I don't really understand the math.

In reply to by [DELETED] 5

@lasonic

I'll check out the developers handbook, thanks. I would love to contribute, if I knew how...!

I'm totally bewildered my Git. It has to be THE most impenetrable thing to understand for a complete beginner to versioning. Slightly OT, but any recommendations for a really good beginners guide to Git/GitHub?

In reply to by douglas81

FWIW, while I agree it takes a while to grasp Git, you don't really *need* to understand much about it if you read the Git workflow document and following the instructions to the letter. That is, it doesn't really matter if you understand what is happening when we run the clone operation or fetch or branch or add commit or rebase or push - just the things it says to do in the order it says to do them in.

In reply to by Marc Sabatella

Just reading your last post again, Marc, about maybe the intention being that it kicks in at much shorter lengths... yeah, that was maybe the original intention. Like when you have a minisucle amount of space between two notes but, for whatever reason, you still want a slur in there. A non-graded super-slim slur might make sense in that case.

Do you still have an unanswered question? Please log in first to post your question.