Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MU4 Issue] Order of notes in unisons is non-deterministic #8993

Closed
oktophonie opened this issue Sep 1, 2021 · 1 comment
Closed

[MU4 Issue] Order of notes in unisons is non-deterministic #8993

oktophonie opened this issue Sep 1, 2021 · 1 comment
Assignees

Comments

@oktophonie
Copy link
Contributor

Unisons exhibit unpredictable behaviour as which note is which is based on the order in which they are stored in memory; anything that causes this to change can result in rendering differences and other problems.

In a downstemmed chord, the upper note of the unison is the one in the normal position, to the right of the stem; the lower note is the one that is offset to the left of the stem.

In an upstemmed chord, the lower note of the unison is the one in the normal position, to the left of the stem; the upper note is the one that is offset to the right of the stem.

In effect, this means the 'lower' notehead is always the one to the left.

This behaviour is analogous to how seconds work (see the examples a-d below). It also remains the case even where there are no accidentals; we need to know, for instance, that the C to the right in example e is the top note.

unisons

This is also relevant for applying accidentals. If, for example, we select the C on the left in example e and add a sharp, the sharp should be applied to the C on the right instead, as the notehead in that position is always the higher of the two.

Similarly, if we select the A on the right in example f and add a flat, the flat should be applied to the A on the left instead.

Whenever an accidental is applied to one note, a natural should always be drawn for the other. This does not always happen currently (it does for the just-described C# example, but not for the Ab one).

Of course, if the same accidental is added to both notes, the accidental will only be drawn once.

The order of accidentals should reflect that of the order of noteheads, i.e. the lower to the left. There is an argument made that an exception should be made for natural/sharp, since that symbol has a separate meaning (cancelling a prior double-sharp). [Personally I'm not absolutely convinced,, for these reasons:

  • it introduces an inconsistency
  • using the natural-sharp and natural-flat in this way is no longer a recommended practice; it's also extremely unlikely to coexist in a score that also uses altered unisons
  • the natural-sharp order is clearer, and arguably even essential, for situations where the notes of the chord represent different instruments (multiple wind instruments sharing a stave, for instance) as it indicates which instrument plays which pitch.

but I'm quite open to being persuaded :)] In any case, we need some means of reversing the accidentals for exceptional situations that arise.

Should fix:
https://musescore.org/en/node/307196

@oktophonie oktophonie added this to To do in [MU4.0 - ENGRAVING] via automation Sep 1, 2021
@oktophonie
Copy link
Contributor Author

Seems to have been fixed already in MU4. My mistake :)

[MU4.0 - ENGRAVING] automation moved this from To do to Done Sep 17, 2021
@oktophonie oktophonie closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

2 participants