Improving support for 2-line and 3-line staves
Right now, from my perspective, 1-line staves work pretty well, but 2-line and 3-line staves not so much. There are mostly used for percussion, and mostly with a larger-than-usual line spacing, but I've also seen some discussion of using them for pitched music as well.
I want to understand what expectations actually are so I can see about making things work as well as I can. I am concerned about things like:
- In a drum set definition, line "0" is normally the top line of the staff, but currently 2-line staves are treated very oddly, with all notes displaying 1sp higher than they actually, causing funny things with ledgers lines, unclear behavior of key signatures & accidentals, etc
- Vertical positioning of rests - they look ok in a 2-line staff with standard line spacing (I think perhaps *because* of the 1sp adjustment), too low I think if you increase line spacing or use a 3-line staff
- Stem length when using non-standard line spacing - stem length scales with line spacing, which I guess might make sense in some contexts but seems strange to me
- For drum staves, it seems the "line" setting should respect the line spacing, so the lines are 0, 2, and 4 regardless of the line spacing, and 1, 3, and 5 center between the lines. Currently, with a 2sp line spacing, you need to use line 2 just to reach the first space, line 4 to reach the second line, etc. But maybe people are depending on this now and creating drum set definitions with this in mind?
As someone who doens't use these features myself, I don't really have a good a feel for what people might actually want or expect; I just know things seem odd to me right now and we do get complaints.
Here are some issues & threads that made me want to look at this:
#19197: Non-5-line drumset stave lines incorrectly positioned
#53686: mismatch between 1.x and 2.0 when reducing staff to 1-line
https://musescore.org/en/node/46651
https://musescore.org/en/node/70346
https://musescore.org/en/node/71526
I'm not thinking of implementing any fancy new controls over which lines map to which - I expect to keep it where a 2-line staff means the top two lines of the standard 5-line staff. Anything else would be too big a change for me to want to look at. But I do want it to at least behave better within this framework.
Comments
BTW, I'm already discovering that some of the handling of line spacing is for tab support, so I would not want to mess with that. So far I've foudn two places where line spacing is used in computing stem lengths, and simply changing it to only do this for tab staves seems to the right thing there, although no doubt there is more to look out for.
The way line spacing is accounted for in note layout also means that on a 2-line or 3-line staff with spacing 2sp (common for percussion), you end up with unnecessary ledger lines apearing even for notes that are physically on the staff. That's because to get a note onto the bottom line of a 3-line staff (for instance), you need to set the line to 8, but since there are only three lines, the note is perceived as being well below the staff and needing two ledger lines.
Again, I propose the three lines be numbered 0, 2, and 4, which would take care of this. But if there is a reason to keep the numbering at 0, 4, 8, then we need to adjust the ledger line code, and probably other places where we try to determine if a note is below the staff or not.
Really, in order to understand the right answer, I need feedback from people who actually *use* line spacings greater than the normal 1sp. I do at least understand something about expected results for 3-line percussion staves. Not sure about other use cases.
Really, I don't mind have a solo conversation :-). Helps me to work out my thoughts.
As I've looked into this, I realize things really are a mess. Voice 2 rests show up way below the staff, ledger lines show up nowhere near the notes they go go with, etc. Luckily, each of the problems I see are easily identified and corrected, so assuming people agree with my impression of what constitutes "correct", this is a pretty easy fix. I did consult Elaine Gould's "Behind Bars" and based most of my changes on her advice and/or examples as well as suggestions made in the issues and threads I references above.
The following shows a 3-line staff with double spaced lines - the default "Perc. 3 lines" style you can select in the Instruments list. The images below show the following changes, which I consider improvements:
- lines numbered 0, 2, and 4
- stem lengths same as normal staves rather than twice as long
- rests in single-voice case centered on middle line
- rests in two-voice case centered on top and bottom line
Also,
- notes on spaces are centered between the lines
- ledger lines are positioned correctly
For two line staves, I got rid of the offset that made line 0 float above the staff, and I tweaked the rest positions for both single-voice and two-voice cases to match Gould:
I made similar changes for 2-line or 3-line pitched staves. For instance, in treble clef, the top line is F and the next line down is D, regardless of how many lines the staff has or what the line spacing is. I made this apply to the key signatures as well. The following example shows a 2-line staff with 1.5sp line spacing.
Notice the clef hangs well below the staff. This is technically correct: it is aligned so the end of the curl within the clef sits on the fourth line from the top and defines the note "G" (which is why this is called a "G" clef). It's quite easily to lie and center the clef, or at least not make it hang down so far, if people prefer that. I suppose it would also be possible to define it so that the two lines were "B" and "G, but I think that would get messier. I'd need a very good reason to try to go there.
For the most part, tab staves are not affected by this. For one thing, I specifically excluded tab from some of the changes, and for another, tab staves go through a lot of totally different code that was already pretty well optimized. I did make the change to rest positioning affect four-string tab:
If someone has suggestions for further changes, or questions about what I did or why, let me know.
Open question: strategy for dealing with scores that have already tried used manual adjustments to work around these problems. I am kicking myself a bit that I didn't look at this *before* 2.0, but oh well.
In reply to Really, I don't mind have a by Marc Sabatella
Just my 2 cents, because I didn't look into it for quite some time.
I believe these staves worked ok in MuseScore 1.3. I liked the strategy of using the same spacing than a standard 5 line staff (since 1.3 didn't have line space settings, since it didn't have tabs) and to consider these staves as 5 line staves with some invisible lines. So using the middle line for 1 line staff, the top,middle and bottom line for 3 lines and so on. The main advantage to me was that the code was not cluttered with test for the number of lines.
That's being said, your result looks ok. I'm just curious how you made it and hope it's not by introducing more "lines == X" tests.
In reply to Just my 2 cents, because I by [DELETED] 5
I did notice that 1.3 scores treat the 3-line staff as basically the first, third, and fifth lines of a 5-line staff (lines 0, 2, 4). I suspect the reason this was scrapped for 2.0 was the introduction of the "Line distance" staff property. In 1.3, 3-line staves were always exactly double spaced, but for 2.0, you can specify any distance you like. Most produce lousy results, of course.
The advantage of keeping the lines as 0, 2, 4 is that then the music stays the same even if you change the line distance. At least I think of it as an advantage. And it works just as well for a line distance of 1.5 or 1.37 as for 1.0 or 2.0.
There are two different but related things going on here: dependency on number of lines, and dependency on line distance. Most of what I did really was just making sure line distance is accounted for in places where it need to be. The only place where there is special casing on number of lines is for the vertical positioning of rests. I could write a cryptic expression that would calculate the appropriate offset from number of lines, but I don't think what I did is too messy. It's just one spot in the code. I think literally everything else is just accounting for line distance.
I just made a tentative PR so people can look at the code and try it out:
https://github.com/musescore/MuseScore/pull/2159
In reply to Really, I don't mind have a by Marc Sabatella
Well, things were a mess indeed and they probably still are. I had a chance to look into this while extending bar line support (about 2 years ago, I think), so I have some recollection but not many details. There was a number of special cases; according to your survey, 2-line and 3-line special cases are still there.
Possibly, by looking through the code for bar line calculation and layout, you'll find some comments I added at that time about those special cases.
I remember having had some discussion back then about 1-line case in order to reduce it to the general case (1-line case is special for bar line height, but can be regular under all other aspect) and I remember (incorrectly?) having regularized it.
I also remember to have converted a rather high number of occurrences of literal numeric constants to symbolic constants or staff-related variables (like "4" being blindly assumed to be the staff height, or "0.5" the distance between line positions), but I am sure I didn't get all of them (I didn't look for all of them, as "0.5" may have a quantity of meanings), so I just converted the ones I stumbled on and about which I was rather sure of the meaning.
Your screen shots look generally fine to me, but I have no real use for non-5 line standard staves so I cannot really tell.
The only detail is the position of the clef: to me it seems strange to have a clef positioned so that it defines a note outside of the staff (even if computations work out correctly), so I would expect that, on a 2-line staff, a clef (any clef, not just the G clef) would be on either of the lines, but not "outside the staff" (and similarly for 3-line or 4-line standard staves). But, as I said, I have no use for these cases so mine is just a "theoretic expectation".
About rest position on tab staves: thanks for looking into the matter; as tab can commonly have any number of lines from 3 to 6, it would be wise not to have special cases, but determine the vertical position of elements algorithmically, if possible.
So, does your change about rest positions in 4-line tab add a special case or extends / improves / corrects an existing (attempt at an) algorithm?
In reply to Well, things were a mess by Miwarre
See my previous response as well. There actually were not inappropriate assumptions about number of staff lines in the code I changed, but there were indeed places where 0.5sp was assumed to be the step size, and simply changing these to lineDistance * spatium helped immensely. In fact, basically there were only three things I did:
1) Factor in lineDistance where necessary (note position, ledger line position, key signature layout). For stem length, lineDistance was *already* being factored in, but I changed that do do so only for tab, since it seems you already handle that well.
2) Get rid of the automatic setting of stepOffset to -2 for 2-line staves, which was responsible for line number assignments being off on 2-line staves and positions being confused even when using single-spaced staves
3) Some special casing for number of lines in the code that computes vertical position for rests. The position of the rests was already determined by a giant switch statement (for each type of rest) with hard-coded constants. Actually, two such switches, one for single voice, one for multiple voices. While I'm sure it would be *possible* to do this more algorithmic, I think it would end up being more complex and cryptic than you might think, because really, according the "right" aswer for 1, 2, and 3 lines staves is kind of quirky if you look at Gould p. 284 and following pages.
BTW, one line staves are a whole other can of worms, because of all the special casing for barline height. But those had already been beat into shape pretty well over the past few months. The only additional thing I did here was improve the vertical position of rests in multi-voice cases.
In reply to Well, things were a mess by Miwarre
BTW, I didn't change anything about rest positioning for staves with *more* than 5 lines, but that would be one advantage of coming up with a more algorithmic approach. There was a discussion here about the expected results for 6-string tab:
#47626: Tablature rests at incorrect vertical position
AlthoughI don't see that Gould addresses this, now that I look at her recommendations for 2-line staves, I'm inclined to think she'd agree with chen lung and prefer the LilyPond positioning of rests over ours. That is, she doesn't seem to have qualms with centering a rest on a space rather than a line.
So unless people object, I'll look at a more algorithmic solution that handles arbitrary numebrs of lines better. The nature of Gould's recommendations is such that I think there may still need to be a little special casing, but I can probably minimized it and make the purpose more clear.