Lyrics top margin representing distance from lowest note of staff in system
MuseScore's default "Lyrics top margin" setting is 2sp, meaning the top edge of lyrics will be placed two spaces under the staff. Most of the time, this 2sp setting will work, but if the voice line falls more than two spaces below the staff (treble clef low-A or lower) there will be a collision.
In practice, the solution is to move the offending lyrics down as needed, but it's awkward for the line to jump in vertical position mid-system, so typically all of the staff's lyrics in the system are moved down to accommodate.
MuseScore doesn't currently do this automatically. The user must do one of the following to remove the collision:
- Globally set the "Lyrics top margin" setting to something higher (creating unnecessary space where there are no collisions, especially in other vocal parts),
- Manually adjust the vertical positions of the colliding lyrics (creating an awkward mid-system vertical position change, not suitable for multiple lines, may also require manual spacing of staff below), or
- Manually adjust the vertical positions of colliding lyrics and the other lyrics in the system (best solution, though tedious, and system rearrangement will require redoing the correction).
I propose that there be an option to make lyric positioning relative to the staff's lowest note in its system, instead of to the bottom of the staff.
| Attachment | Size |
|---|---|
| lyric-positioning.png | 141.93 KB |
| lyric-positioning2.png | 141.24 KB |
Comments
Yes, this would be good some day. Also a way to specify a lyric as being above staff, I in which case the "top margin" is inverted or ignored. These features should probably be developed together to make sure they are compatible.
I'd rather have it as a min value, getting increased automagically (and for the whole line) if it collides with notes (or slurs)
And yes, inverting it when above staff makes sense
We could have a min and a max value, like for staff distance, maybe?
I am interfering quickly and on tiptoe :) in your debate to say that the issue is the same for text.
![text.jpg]( "text.jpg")
staff text (and system text) that is. Probably also chord symbols, tempo text, dynamics etc. pp.
There doesn't appear to be a value containing a SysStaff's highest/lowest notes (or other notation), but these could prove valuable for laying out and avoiding collisions. Lyrics and chord symbols must be horizontally aligned, but vertical spacing can vary between systems.
These values can also help with spacing out adjacent staves. If you look at a multiple-voice section of a piano piece, the two staves are probably spaced further apart.
I think SysStaff should contain cached values of the highest and lowest positions of its constituent notes, including stem and articulations (and maybe in the future, slurs and ties). That way, when spacing out lyrics, chord symbols, tempo, staff text, or adjacent staves, the "y" value could be adjusted accordingly.
Just another thought: it would also be useful to include an element-wise toggle for inclusion in this calculation. Say you have a note that is really far from the staff, but doesn't collide: you would not want all of your lines of lyrics/staff text/etc. to accommodate it, since they don't need to.
Yes, automatic collision avoidance is a good thing in general, not just for lyrics. And not just vertically - what about a staff text on one beat colliding with a staff text on the next? Or staff tyext colliding with articulations. And so on an so on. Really getting totally completely automatic layout is way beyond anything we are clsoe to right now, and based on how it works with LilyPond, would slow MuseScore to a crawl.
So I think it makes more sense to tackle this one piece of the puzzle at a time. Staff texts are easy enough to move one at a time if there are collisions, and there is no typesetting convention I know that says they must all be aligned vertically. So even if we added some automatic code here, it needn't affect the entire system. Lyrics are special in that if there is one lyric, there wil probably be a whole line of them, and they are all supposed to align vertically within a system.
Anyhow, these are the sort of changes probably best to discuss with Werner first. The order in which things are laid out is a very sensitive thing, as many aspects of layout are interconnected. It *really* easy to break things here. There are a number of other changes to how some of those interconnections work that probably make sense some day - not the least to make it possible to optimize things to not require relayout of the entire score every time you make a one-note change.
BTW, FWIW, Finale provides a reasonably effective mechanism to avoid the need for fully automatic positioning but still make it easy to adjust all lyrics (or staff texts, or dynamics, etc) for a system, or for a staff: a special set handle that appears at the left of each staff (when in the apropriate mode) that basically selects all elements in that system or staff and lets you move them together.
Because MuseScore doesn't have separate "modes" for working with the different element types, that doesn't exactly make sense. But actually, we already *do* provide something kind of similar. Right click a lyric in the problem system, Select / More / Same system. Now adjust manually using Inspector. It's maybe a bit more awkward than one would like, but it seems that this is already the basis for a much less invasive improvement - just make this easier to access somehow.
Hmm, one possible idea - a new command to automatically select all similar elements in same staff / system and adjust them to the same vertical position as the selected item (ie, copy the user offset). So you find the one lyric that needs most adjustment, adjust it manually, then issue the new command, and it's done. Probably doable as a plugin, or possibly worth including in the new Edit / Tools menu.
Another possible idea - two new commands, "copy offset" and "paste offset". Adjust one syllable, "copy offset", select the rest of the system, "paste offset" (which could be smart enough to only work on same type of object as the original. This could perhaps be incororated into the existing selection filter facility. This could be more generally useful, but would be a bigger change.
Dynamics, staff text, and system text need not be vertically aligned with respect to like elements in system; indeed, it is common to see variable vertical alignment of dynamics, sometimes even requiring diagonal hairpins. Also, it is generally permissible to move these elements horizontally to avoid collision (e.g., simultaneous staff text and dynamic for a piano part).
Like Marc said, lyrics are special. When they exist, there are generally one or more lines of them, all of which must be vertically aligned with respect to other lyrics within a system. (A similar case could be made for chord symbols, but not as strong, since there is only one line of chords, and the elements are distinct: they are not meant to be read together like words are). Consequently, an effective collision avoidance algorithm is simply adding "extra space" above the lyrics. This extra space is simply the difference of the default y position and the y position of the lowest notation.
Lyrics are common notation elements that are frequently subject to collision in MuseScore; I would even argue the most frequently when they are used. Also, compared to staff/system text and dynamics, the current mechanisms for correcting them are more painful because lyrics should be modified in bulk (This is made easier with new selection mechanisms, but are still subject to manual reassessment if the notation changes). These two reasons exemplify the need for a more automatic solution specific to lyrics, and the one I proposed seems simple enough to at least test out.
Select/More/Same system *and* same staff, or else you'd select lyrics for all voices. My current solution is actually "Select -> All similar elements in Range Selection". However, this often requires a staff spacer down, since the lyrics lower margin should be increased accordingly but is not.