Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MU3] fix #314665: don't force "long" slurs above the staff #7148

Merged
merged 1 commit into from
Mar 4, 2021

Conversation

MarcSabatella
Copy link
Contributor

Resolves: https://musescore.org/en/node/314665

NOTE: I am confident the code itself is good,
not as confident we want to make this change for 3.6,
at least not without adding more compatibility handling.
But I wanted to make this available for testing and discussion.

We have code to force "long" slurs above the staff,
which isn't a terrible idea, but we're way too heavy-handed about it.
Anything more than one measure in duration is considered long.

Since this determination is best made subjectively by the user,
the code here removes this check.
However, it will doubtless have an efrect on existing scores.
In most cases, a good one, as slurs that were erroneously forced up
will now be where they really belong, below the staff.
In some cases, though - especially truly long slurs
like ones extending for most of the system -
it could cause too much extra space below the staff.

Ultimately we could consider adding a style setting to control this.
And having the default different for older versus newer scores.

Resolves: https://musescore.org/en/node/314665

We have code to force "long" slurs above the staff,
which isn't a terrible idea, but we're way too heavy-handed about it.
Anything more than one measure in duration is considered long.

Since this determination is best made subjectively by the user,
the code here removes this check.
However, it will doubtless have an efrect on existing scores.
In most cases, a good one, as slurs that were erroneously forced up
will now be where they really belong, below the staff.
In some cases, though - especially truly long slurs
like ones extending for most of the system -
it could cause too much extra space below the staff.

Ultimately we could consider adding a style setting to control this.
And having the default different for older versus newer scores.
@igorkorsukov igorkorsukov changed the title fix #314665: don't force "long" slurs above the staff [MU3] fix #314665: don't force "long" slurs above the staff Feb 5, 2021
@vpereverzev vpereverzev merged commit 7681e67 into musescore:3.x Mar 4, 2021
@Jojo-Schmitz
Copy link
Contributor

I wonder whether this would need to get ported to master

@MarcSabatella
Copy link
Contributor Author

Well, I assume the same change should apply there. Although at the time, the belief was that the slur algorithms were going to be rewritten more completely.

BTW, this PR probably should not have been merged for 3.x. Or at least, it's one that should not be included in any hypothetical 3.6.3, as it has too great a potential effect on existing scores.

@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Aug 4, 2021

It doesn't cause any vtest issues as far as I can tell. And I haven't noticed any other issue with it.

@MarcSabatella
Copy link
Contributor Author

Not surprising there isn't a vtest for this particular case, it only affects "long" slurs. But it very definitely changes the default position of slurs in many cases, that is the whole point.

Right now, this the default for the following cases:

image

The reason the first slur is below the staff is that normally one keeps slurs on the notehead side. But there is code to enforce a "rule" that says to place "long" slurs above the staff regardless of stem direction, and the second one qualifies as long while the first doesn't. it's quite arbitrary, really, and @oktophone had expressed the opinion this rule is not really worth implementing.

So this PR changes the second slur to be below the staff, This will affect a lot of scores. it's a good change, I think, but not one to consider for any 3.x release, were there to ever be such a thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants