Collision avoidance applied to cross-staff notes in multi-voice context as if the notes were on the same staff

• Sep 4, 2014 - 11:59
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Steps to reproduce:
1. Create an empty score with one staff.
2. Create a whole note.
3. Add a lyric and an articulation to the note
4. Select the note and press X.

Expected: The note should stay in place.
Result: The note moves left or right.

Experimenting with Shift-X also produces interesting results. The pain point is when multiple staves have corresponding lyrics and articulations; some of them would be misaligned depending on the note's stem direction. This is not an issue for stemmed notes, unless they are brought to an adjacent staff with Ctrl-Shift-Up.

Using MuseScore 2.0 Beta (1efc609) on Windows 8.1
Also present in the the latest nightly at the time of writing (e89b028)


Comments

I believe this is an unintended consequence of the fact that MuseScore tries to center whole notes above/below other notes, and the way this is done apparently throws off the MuseScore's calculation of where the lyric syllable should be attached. That is, it's actually the layout of the lyric syllable, not the note itself, that causes the position change. What's weird is it always get alignment right for whole notes regardless of stem direction (which *is* calculated even though there is no stem) when it is not flipped.

I'd like to fix this if I can, but can you show an example where this change in position on stem flip is a problem? You mentioned misalignment, but so far, while I can see that the lyric is in slightly different positions relative to the articulations (or to the note itself), I can't come up with any cases where this actually a problem. I assume you are not *really* flipping stem directions on whole notes and that the misalignment you speak of could occur in multi-voice situations where "stem directions" of the whole are naturally flipped. But as far as I can see, everything does stay well enough aligned, even with multiple staves involved.

Shift+X does of course move the note out from under (or over) an articulation, but that's normal and to be expected. The whole point of Shift+X is to move one notehead to the "wrong" side of the stem, while leaving everything else about the chord - other notes in the same chord as well as markings like articulations that are attached the chord as a whole and not to individual noteheads within the chord - unchanged.

See the attached PNG. You are right; the problem only occurs in multi-voice situations. It doesn't seem to be related to lyrics at all, so perhaps this should be filed as a separate bug.

In the first measure, the 2nd voice in the top staff belongs to the top staff. In the second measure, the 2nd voice in the top staff belongs to the bottom staff, and it was moved up to the top with Ctrl-Shift-Up.

What seems to be happening in the second measure is revealed by changing the pitch of the 2nd voice note. It will move left and right to avoid colliding with the 1st voice in the bottom staff (specifically, a non-existent note on the second space of the top staff), and it will collide with the 1st voice in the top staff.

Attachment Size
stem-articulation-alignment.png 33.91 KB
Title Stem direction of whole note with lyric affects horizontal alignment of note and subordinate elements Cross staff notation producing unnecessary offsets to avoid collision with notes in other staff

Wow, so that's a high D in the bass clef staff, moved to the top staff, and then I guess you flipped the direction of the stem on the top note manually? Was this also going on in your original example with the whole notes? I am tentatively assuming yes, and changing the title of the issue to better reflect what is actually happening.

Assuming this is true, what you are actually seeing is not about stem direction of whole notes at all but about the collision avoidance algorithm not "getting" that the note it is trying to avoid is in a different staff. I've always wondered if there wouldn't be cases like this that could cause problems, thanks for the confirmation :-)

So I guess my next question is this: is there some sort of real life scenario in which this highly unusual arrangement of notes is needed? Cross-staff notation is not that unusual, but you've got cross staff notation combined with a situation where it's actually the logical *bottom* voice (bass clef voice 2) that has been moved above the "middle" voice (bass clef voice 1). It's that voice crossing that is responsible for triggering the effect.

I assume I can fix the issue, but I don't know what other ramifications it might have, so I'd still like to see an actual real life score to try it with.

Sorry Marc, I meant to say the stem-direction problem has to do with multi-voice situations with cross-staff notes. It seems there are two issues:

1. Whole notes with lyrics: Create a score with two staves, add a whole note to each staff in the first measure such that their stems would be in opposite directions, and add a lyric to EACH whole note. The lyrics are misaligned, and no manual stem direction change caused it.

whole-note-lyric-alignment.png

This issue comes up when transcribing a song with multiple singers, such as one for an SATB choir. If everyone's on a whole note, the "stem direction" of the notes causes the corresponding lyric to be offset, and then the lyrics are no longer perfectly aligned. A temporary solution is to force all whole note stems to one direction.

2. Multi-voice cross-staff notes: Create a score with two staves, add some notes to one staff, then add a second voice to that staff at the same metric position. Move the second voice to the other staff and change its pitch such that it would visually collide with the first voice (i.e. 3rd line, 2nd space; clef doesn't matter). The displaced note will attempt to avoid the note on the first staff, even though it's not on the staff it's currently on.

stem-articulation-alignment2.png

This issue isn't as bad, as I believe the main reason for cross-staff notes is to cause the other staff to be empty at that position (not even rests). In this primary use case, there's never a second voice to collide with. If there were, you'd simply use the second voice of the existing staff. I have attached the score where the problem occurred. Technically, the notes in the top staff are played with the left hand (as the original notates with cross-staff lines) so I used the Ctrl-Shift-Up method of moving the 2nd voice notes, whereas I could have simply used the 2nd voice of the top staff and avoided this problem.

OK, I get the whole note issue now - the *notes* are aligned, but the *lyrics* aren't necessarily.

So it seems there are actually two unrelated issues. One involve how lyrics are centered when whole notes of different "stem directions" are involved, and a totally separate issue involving how the collision avoidance algorithm works in the presence of cross staff notes. Could you file one of those separately, and change the name of this one back if appropriate?

Title Cross staff notation producing unnecessary offsets to avoid collision with notes in other staff Collision avoidance applied to cross-staff notes in multi-voice context as if the notes were on the same staff