The Official Layout Improvements Feature Request Thread
A couple of months ago, I posted a topic called "Smart" positioning , essentially asking for MuseScore to intelligently layout element to avoid collisions. I learned that this would be an incredibly complex task, but Marc Sabatella told me "I suspect we'll probably start small, looking for specific collisions that are considered especially likely or especially problematic, and then work out way from there to covering more cases over time."
Marc Sabatella, of course, has famously done some brilliant work improving MuseScore's layout algorithms: Improved Note / Accidental Layout In MuseScore 2.0 (and it turns out that in comments there that I had not previously read basically the same idea was brought up).
But, any task can be accomplished if you break it into small enough pieces. So, here's my idea: to have a series of very small, very specific requests to improve the layout of specific things. All added to this thread, hopefully discussed a little bit, and then filed in the Issue tracker . When one is taken care of, we move on to another.
So, I'll kick us off with one I mentioned once before.
Put a few Bs on a treble staff (the middle line). Tie a couple of them together, and then put an accent (a regular sforzato) on the note that starts that tie. The result does not look good at all:
In sheet music I've seen, in this situation the accent is bumped up a space, actually to above the staff, so it looks like this:
It should be noted that it's only the note on the middle line of a five-line staff that has the issue, but I hope it's fairly easy to teach MuseScore the solution.
I'd like to get some opinions before I file the request in the tracker. Any thoughts?
Comments
I like the idea of tackling some specific problems that can be solved without a complete overhaul of the layout system as some improvements might require.
The one you describe above is actually the sort of the thing that already is implemented to some extent - except not this particular case. Replace the accent mark with a staccato dot, and the tie with a slur, and you'll see we already do some special casing. The trick would be to add more without making making the code unsupportably fragile / hard to support. A complication is that the results differ according to note spacing - with looser spacing, the accent doesn't actually touch the tie and doesn't *need* adjsutment. Also, try adding another note to that chord - while still forcing the stem down - and you'll see the tie is repositioned and no longer presents a problem. So it's really a special case on top of a special case: only middle staff line, only when a single note, and not necessarily needed if the spacing is sufficiently loose; It's dealing with all those sorts of variables that starts moving this in the direction of things that really need a more general solution based on overlapping bboxes (see, there is a reason you needed to learn about them :-)
In reply to I like the idea of tackling by Marc Sabatella
Matters could be simplified significantly if we didn't try to account for different spacing. For example, I don't think it's a problem at all to have
![AccentTie4.png]( "AccentTie4.png")
![AccentTie3.png]( "AccentTie3.png")
instead of trying to maintain
in cases of looser spacing. This is, in fact, exactly the way Sibelius does it; it's just hard-coded that, if there's an accent and a tie, and the note is on the middle line of the staff, things will always be placed this way, regardless of spacing.
By the way, I'd like to extend the request to slurs as well as ties.
In reply to Matters could be simplified by Isaac Weiss
Issue created at #63846: Place sforzato accent one staff space higher if note on middle line of staff has tie or slur.
Add extra vertical spacing when needed to avoid collisions between the markup of note on the upper staff and the notes on the lower staff. Example:
To render this example properly I have to add vertical spacing, which is annoying because the spacing must be added each time this pattern appears.
In reply to Add extra vertical spacing by GEB
What about the notes themselves? If that low note were a bit lower, it also would overlap.
Right now we allow extra space for lyrics only. We don't track the space needed by notes/chords or elements attached to them. This also includes chord symbols and other text. I don't think I'd want space added always the way it is for lyrics - only if necessary. Make sense?
In reply to What about the notes by Marc Sabatella
Yes, it makes sense.
I was talking about adding space only if necessary, not always.
You'd need to start tracking the space taken by chords or notes for this to work, if the computational cost is not prohibitive.
Handle grace notes followed by a chord with accidentals, as descibed here http://blog.steinberg.net/2014/12/development-diary-part-nine/
This image shows how some score editors handle this situation (C is LilyPond and E is Musescore):
Musescore (as well as Products A and B) typesets the grace note too far away from the cord.
In reply to Handle grace notes followed by GEB
FWIW, this type of enhancement is being looked at (by Werner). Right now spacing decisions are based on assuming elements attached to notes/chords have to lay out left to right. There there is no allowance for allowing them to overlap if they clear each other vertically. In theory, this is doable with only moderate effort.
Add rounded corners to ledger lines (like LilyPond does). In my opinion, ledger lines look better with rounded corners than with straight corners. In addition, rounded corners would be consistent with the rounded corners of the note stems.
Examples:
LilyPond
.png)
Musescore:
.png)
In reply to Add rounded corners to ledger by GEB
Issue created at #63851: Add rounded corners to ledger lines instead of straight corners.
Well, clearly my idea wasn't very well developed, because we're getting one idea after another without discussing any of them in depth or filing feature requests before suggesting a new one, and the only person weighing in is Marc. So, do you think we should officially cancel the Official Layout Improvements Feature Request Thread?
I'll file feature requests for each of the things that have been brought up above. Thanks to all who brought their ideas.
In reply to Well, clearly my idea wasn't by Isaac Weiss
I think continuing to list ideas here is good. Some don't really need much discussion, they just need to be done. One nice thing about having this thread rather than a bunch of separate feature requests is that once there are a bunch of suggestions, we can start talking about group related ones, prioritizing, etc.
I'll post this here but then add it to the tracker promptly.
Rehearsal mark at beginning of system should stay within margins
MuseScore positions certain things relative to the beginnings of measures, which makes sense. But with rehearsal marks, the specific way that MuseScore relates them to barlines leads to the following result if the rehearsal mark is at the beginning of a line:
![a.png]( "a.png")
The volta included in the picture is correctly positioned by default, and could be a model for the positioning of the rehearsal mark.
Here is a manually created example of correct positioning for the rehearsal mark in this circumstance (though the number of staff spaces of horizontal offset depends on the key signature):
![b.png]( "b.png")
Issue created at #63856: Rehearsal mark at beginning of system should stay within margins.
In reply to I'll post this here but then by Isaac Weiss
"Correct" is subjective. I much prefer the current layout to your proposed example.
Also, unlike the case with voltas, which are always positioned automatically with no user control over the defaults (except vertically), rehearsal mark normally respond to text style settings. And the default text style for rehearsal marks is centered. I'm not really comfortable with the idea of MuseScore deliberately ignoring the text style. We do it to override lyric alignment because there are pretty universal rules for when to center versus when to right align.
That said, a style option to control whether rehearsal marks align to the barline or some other point in a measure could make sense.
In reply to "Correct" is subjective. I by Marc Sabatella
Rehearsal marks at the start of a line are positioned on top of bar numbers (at the start of the line). Adding a system of spacers (and -negative spacers) to avoid overwriting objects that potentially share the same position would be useful.
Here's a great idea for hairpins and dynamic marks .
Also, somehow I failed to find this before creating this thread, but the topic has also previously been discussed at Improved automatic placement of score elements .
Current master moves ahead in terms of auto-placing:
![collision_detection.PNG]( "collision_detection.PNG")