Wrong(?) default placement of slurs
It might be a matter of taste, but in some cases, I am dissatisfied with the default placement of slurs. See the examples. These slurs had been added with "block select" + "S", I haven't changed anything manually. I think the slur is placed too far away form the noteheads, it doesn't "stick" as it should. (More examples attached.)
| Attachment | Size |
|---|---|
| 2021-02-04 20_04_31-Window.png | 8.07 KB |
| 2021-02-04 20_04_09-Window.png | 7.17 KB |
| 2021-02-04 20_03_40-Window.png | 13.59 KB |
Comments
Your first attached/inserted image: I don't get the same result.
See:
![slur.jpg]( "slur.jpg")
![2021-02-04 20_03_16-Window.png]( "2021-02-04 20_03_16-Window.png")
Compared to yours:
In reply to Your first attached/inserted… by cadiz1
Try adjusting the beaming. Nevertheless, the slur is too far away in both cases.
In reply to Try adjusting the beaming… by szekelyga
Maybe something related to the time signature?
Which is this time signature for you?
In reply to Eventually something related… by cadiz1
3/4, and in the properties I have adjusted the beaming to connect 6 eighths. It doesn't (shouldn't) matter.
For reference (from the same score): this is what a correctly placed slur looks like:
![2021-02-04 20_20_33-Window.png]( "2021-02-04 20_20_33-Window.png")
In reply to 3/4, and in the properties I… by szekelyga
For some reason, I thought I saw a different result between a 3/4 and 6/8 measure, for example. I can't do it again, I must have missed something (or change something, except editing the default beaming). Let's forget it.
It's much easier to assist given an actual score instead of just a picture. Slur positioning is very tricky and depends on many, many factors. In your example, it's almost certainly the natural sign on the C causing the problem. If the end point of the slur were closer to the note, it would then have to be a very steep curve to avoid the natural. So instead we choose to move the endpoint further away. it's a subjective call with no one right answer, but you can always manually adjust to whatever you prefer. You may sometimes need to disable autoplace first for the slur by pressing "=" or using the Inspector. In this case, you could also simply stretch the measure a bit so that natural sign isn't so much in the way. Or disable autoplace for the natural and allow the slur to go through it. Lots of possibilities you can select from.
In reply to It's much easier to assist… by Marc Sabatella
What about the other examples? There is no accidental here:
![2021-02-04 20_04_09-Window.png]( "2021-02-04 20_04_09-Window.png")
In reply to What about the other… by szekelyga
I am no professional engraver, but it should be something like this:
I took me more than 5 minutes to achieve this manually (by adjusting Bézier nodes), so that's a no-go. It is also painful that you have two - equally inconvenient - options to do this:
1) You keep "automatic placement" switched on - in that case, the program randomly changes the nodes' positions after you have worked on them (when you click away from the slur). This is especially painful if you have done a lot of adjustments, and everything is lost without warning when you are finally finished.
2) You switch off "automatic placement" - in that case, the program resets all positions of the slur: placing, size and shape to an equally random "default", and you have to start from scratch with the placement, and can't use the original "automatically placed" version as a starting point.
In reply to I am no professional… by szekelyga
.
In reply to What about the other… by szekelyga
> "It's much easier to assist given an actual score instead of just a picture"
Just picture examples aren't of much help if you not also include the score file for analysis.
In reply to > "It's much easier to… by jeetee
It's pretty hard for me to believe that you can't reproduce this, as it is quite straightforward, but here you go.
All the ones colored with red are poorly placed.
Slurring_example.mscz
I think sometimes it is unavoidable for slurs to collide with accidentals. You will see that in professional scores, but you will never see something like this:
I would never pay money for a score that looks like that.
In reply to I think sometimes it is… by szekelyga
In this case (your file), it is the first note that poses the "difficulty". From G1, and below, you get this (1st measure), and from A1, and above, you get what you point out: 1Slurring.mscz
In reply to In this case (your file), it… by cadiz1
It is a general problem that needs general solution. The algorithm that calculates the slur position might need some adjustment.
In reply to It is a general problem that… by szekelyga
What happens:
In reply to What happens: [inline:Video… by cadiz1
Yup. And?
In reply to Yup. And? by szekelyga
And? Well:
1) What, if any, would be your "ideal" proposal in such cases ?
And
2) Above all, let's wait for Marc's comment, who knows this subject better than anyone else.
In reply to And? Well: 1) What, if any,… by cadiz1
My proposal is to fix this because it is wrong, just like a lot of other positioning defaults that came with the new version.
In reply to My proposal is to fix this… by szekelyga
This is not the answer I was expecting. You're talking about "a lot of other positioning defaults"? I'm talking about a specific case, for the moment, the one corresponding to one of your files, and my GIF. One thing at a time.
Naively, for my part, I would have said: why the slur suddenly changes direction between the A and the G (first note). It seems to me that maintaining the shape of the slur as with the A (and lower) would be a good thing.
But perhaps I will be told that it is much more complex than it seems at first glance, or that there must be a reason that I ignore, or that if one does that, it could break other more frequent cases. I don't know! As said, let's wait Marc's answer, it's preferable :)
In reply to This is not the answer I was… by cadiz1
.
In reply to I think many (most?) of the… by szekelyga
I quite honestly don't know what kind of "solution proposal" do you expect from me. I expect a better slur positioning, because this one is poor. I am no engraving expert. The team should consult the "master engravers" who advised them to do the changes they did for the new version, and ask THEM for a solution proposal, maybe.
In reply to I quite honestly don't know… by szekelyga
Bad mood! Relax, please :)
And let's wait "quietly" for Marc's comment which will know how to temper things and explain all this, as usual.
In reply to Bad mood! Relax, please :) … by cadiz1
.
In reply to I quite honestly don't know… by szekelyga
Yes, our engraving expert Simon is working on some proposals for better slur positioning in future versions.
But the complication is, there is no one right solution to thorny problems like this. No matter what algorithm you choose, there will be many cases where it looks good, and a few where it doesn't. It doesn't mean the algorithm is bad, it's just that there is no One True Algorithm or even One True Right Result for cases like this. Every single notation program ever written or that ever will be written has cases where you need to fiddle with things manually, that's just a fact of life.
So, hopefully we'll see some improvements to defaults in MuseScore 4, with fewer cases where you need to adjust manually, but the reality is, such cases will always exist, and for the time being, this is one of them. You are correct that professionally-edited scores won't have slurs like that, but that's not because the programs that produced them were magic - it's because professional engravers know they need to adjust slurs by hand, a lot. Many will say it's the one thing that takes the single biggest block of their time.
In reply to This is not the answer I was… by cadiz1
If I'm understanding correctly, in your example, the slur changes direction as you change pitch because the stems do - stem direction is one of several factors that go into the determination.
In reply to If I'm understanding… by Marc Sabatella
No, my original post has nothing to do with stem direction.
In reply to No, my original post has… by szekelyga
I was responding to the video in cadiz1's post.
In reply to Yup. And? by szekelyga
Same thing happens in 3.5.2:
In reply to Same thing happens in 3.5.2:… by jeetee
Interesting, I don't remember this.
In reply to Interesting, I don't… by szekelyga
That slur is even worse than the one in the new version. I don't remeber that it was so bad.
In reply to That slur is even worse than… by szekelyga
To be clear, the slur layout algorithm hasn't changed in years. The only thing that changed about slurs for 3.6 is the default thickness of the slur. I actually did implement one small improvement but we elected not to include it because it would change behavior for existing scores in an unexpected way. If you're curious, see #314665: Slurs forced above staff when extending over more than one measure.
The issue you are seeing here only affects those very few slurs with large leaps from the first to second note and with an accidental on that second note. For MuseScore 3, we did make a lot of improvement having to do with how slurs responded to such large leaps as well as to accidentals, but this specific combination indeed is still not ideal - not that there is One True Ideal here.