Left alignment of lines and cross-system elements
Hi everyone,
I would like to discuss some subtle but important notation practices regarding lines that cross systems. Consider the following score:
There is an ottava, a volta, a crescendo, a tied chord, and pedal marks that all cross systems. In my opinion, many of these elements have poor horizontal alignment. (Some elements were moved vertically to avoid collision, but no element was moved horizontally.)
1. Ottava segment starts on chordrest. OK
2. Ottava, pedal and volta segments end at system barline. OK
3. Continued ties start slightly before the connected notes and after key signature. OK
4. Continued crescendo starts on chordrest. OK?
5. Ties and crescendo touch end barline. NOT OK
6. Volta in system header starts at barline. NOT OK
7. Continued pedal and continued volta start on chordrest. NOT OK
8. Pedal line ends on chordrest. NOT OK
9. Ottava and pedal lines do not line up. NOT OK
#6 and #7 are particularly debatable (except for the colliding pedal segment; that's definitely a problem). There's no collision if you move the volta up far enough, but referring to some published works, if the volta is in the system header, it should start and continue just after the clef - that way the start and continuing segments are always aligned, and the systems can have the leftmost margin. I think it leads to better readability, akin to indenting the first line of a paragraph. It also seems that rehearsal marks should take this position, too, if they are in the system header.
Other sources suggest that these segments should start and continue after the key signature, thereby aligning with the ties. However, currently SlurSegments have their own special way of managing themselves cross-system, so getting anything to align with them perfectly would require some significant changes.
Here is the same score with #6 and #7 fixed by special-casing voltas and pedal lines in the SLine layout().
| Attachment | Size |
|---|---|
| musescore2.png | 150.76 KB |
| musescore2-annotated2.png | 245.23 KB |
| possible-fix1.png | 151.58 KB |
Comments
Other weird glitches I noticed while attempting to fix this problem:
1. I manually disabled the hook in the final pedal segment in Volta 1, but it was not saved to the score.
2. Sometimes moving a volta with Shift+arrows causes a crash (el->parent() == this assertion error; probably my fault)
3. There are only two dots on the three tied notes in Measure 2 of the example.
4. On clefless systems, sometimes invisible clefs are created automatically, causing voltas to have inconsistent indentation.
In reply to Other weird glitches I by CombatCube
Let me address the glitches first, as I need to give the rest more thought.
1) There have a number of issues with hooks not saving / loading properly. I think they have to do with the code to only save if something is not the default. See
#25245: Line property "Hook" not preserved on save/load
#27966: Volta end hook in 1.3 score not preserved
#9567: Start hook property for voltas not saved
It's possible the fix for one of those broke your case.
2) When you say this could be your fault, you mean, it could be your preliminary code that is causing the crash?
3) There are three dots, most likely - two of them are overlapping. The code to figure out how to place dots tries to deal with situations like this where two notes should both have their dots in the same place, but it can't always get it. The right answer in this case is for both of the bottom two notes to have their dots *below* the line they are on. I believe that currently, the code to do this automatically only moves one of the dots. To workaround, click the bottom note, Inspector, Dot position -> bottom.
4) "invisible clefs" or clef segments with no clef element? I could see the latter happening for sure. The layout code could definitely be more flexible about such things, as we are discovering regarding "C" key signatures which are sometimes present and sometimes not. We've fixed the layout code to handle that as much as we can, but it's not surprising to me if there are related issues still.
I agree with your assessment of the situation, except perhaps for #9, which is a don't-care for me. And your proposed fix for #6 7 #7 looks good.
Regarding #8, I've posted this in other contexts lately, but it bears repeating:
For the end of a pedal line, we could either change the acutal representation of pedal lines - which does *not* excite me at this point - or change the layout to special case on the type of end hook. For the angle hook, assume it will be followed by another line on the same tick and thus end the line at the note. For the straight hook, assume the marking is the actual end of the pedal and should extent to the end of the note. The latter is already done in the case of single-note pedal marks (eg, under a whole note in 4/4). I think this should play well with your PR fix the playback of the pedal changes, which also preserved the current representation but changed only the behavior as far as I know. Would be nice to see both of those changes go in - this has been gnawing at me for months now.