accidentals on shared note heads
Could not find a definitive answer in search so asking for clarity. Sorry if this was already answered. The image below shows a shared note head between two voices with a D natural. There are two accidentals, one for each voice. Can I assume if only one accidental is shown, one of the notes does not have an accidental applied? I ask this because in editing a copied measure and moving the notes up or down in tone, the notes always display two accidentals, but at times if I am in insert mode and the existing note already has an accidental, inserting a note from another voice with the the duration and matching accidental selected, the note is inserted on top of the existing note, but only one accidental is shown. Further the playback exhibits no dissonance that occurs when the notes are not equivalent in tone. In other words are there any situations where matching shared notes are shown with only one accidental, or if each note has an accidental, both are always shown. I assume if you only show one accidental that applies to both notes, it is impossible to tell whether one note is unmarked or not.
| Attachment | Size |
|---|---|
| NoteHead.jpg | 7.57 KB |
Comments
If you apply the accidental using the toolbar or palette, it is always visible unless you do something to hide it. If you create an accidental by using arrow keys it is visible only when necessary. This is true if the noteheads are shared or you have a measure that has something like a key signature of C major (no sharps or flats) enter a B on beat 2, make it a Bb then enter a B on beat one and change it to a Bb. The flat on beat 2 will follow the rules I explained. The visible flat may be the desired result and the user should be permitted to do this. The fist case can be confusing and should never happen by default, especially when there are two flats on shared notehead B's. Bbb is a common enough note that at first glance it might seem correct.
This is a problem and I know oktophonie (the engraving specialist MuseScore hired) is aware of this and has plans to fix it, perhaps in 3.6 but definitely in 4.0.