Two voices each with an accidental
1) A note in Voice #1 with an accidental (e.g. Bb in a base key signature of C) is added to a stave.
2) A second note (same value, and also Bb) is added as Voice #2 in the same stave.
3) On the screen, and in printed copies, the notes are merged into one note body, but the accidental to the left is repeated, and therefore appears on the screen (and print) as a "double flat". To a musician, the quick indication is that the two notes are to be played/sung as the base note but taken down two semi-tones, rather than each of them down one semi-tone.
I recommend that (as is normal for commercial scores - where only one accidental is shown), MuseScore software be modified to show only the one accidental if both notes are the same.
If the two notes are different (i.e. one has an accidental, and one does not), the two notes should be separated and shown side-by-side - as is the case if the two notes have different values.
This is exactly what is happend inf I do it in MuseScore 3.0.5 on Windows 7
So I can't reproduce your issue/complaint?
I've seen what the OP describes on occasion, so I've simply deleted the extra flat...bad me for not reporting the bug immediately. I'll keep this in mind while I do my work and see how to reproduce it when it happens again.
In reply to This is exactly what is… by Jojo-Schmitz
It's a little tricky to reproduce, but these steps appear to work every time. Score and image also attached showing the issue.
N (for note entry mode)
B (to enter a B)
Click on the Flat symbol in toolbar (to make the B a flat)
Back Arrow (to cursor over first note)
(2) in toolbar (to select voice 2)
B (to enter a B in 2nd voice) - it appears as two notes with a flat and a natural (as expected)
Click on Flat symbol in tool bar (to flatten voice 2 B)
Now the note is shown as one (with an up-stem and a down-stem but has two flats in front of it)
Note: if you use down arrow after entering B to make the note flat you don’t get the issue at all, but instead get expected behaviour. You can (usually? always?) make the issue go away but selecting a note and using the up/down keys to move it up and back down again.
Confirmed. Check this (from an mscx file):
That 2nd accidential has an additional
<role>1</role>. It doesn't have that when having used the arrow key to lower that B to a Bb
Pardon me for saying so, but that is exactly what you are telling MuseScore to do. The recommended way to change the pitch of a note is to use the arrow keys. By performing those steps, you are basically telling MuseScore to draw one flat for the first note and another flat for the second note.
still it reacts differently in the score, see above, only the 2nd one gets this extra setting, regardless being created the very same way as the 1st
Indeed, the main difference between using the toolbar and using the arrow keys is that the toolbar says "I definitely want this flat sign to appear, I'll let MuseScore worry about whether it results in changing the pitch or not" whereas the arrow keys say "I definitely want the pitch to change, I'll let MuseScore worry about whether an accidental should appear". Applying a flat sign to a note that is already flat means you asked for and got the flat sign.
That said, we could perhaps detect this as a special case somehow, maybe not apply the "role = 1" to the second flat if we detect there is a note of the same pitch in another voice.
I believe the real problem here is that MuseScore thinks that the new B should be a natural at first, instead of taking the accidental from voice 1 like it would if you were entering a B on a later beat within the measure. This can be fixed with this code change.
Which I expected to happen, but just noticed that it does not. So please submit this as a PR.
You're right of course, for some reason I was thinking we kept accidental state completely separate for voices.
See this though:
the b shows before the 1st note, which is a plain B, but the 2nd is a Bb, so there's still more to it?
That notation just says: there's 2 notes, one is a B, the other is a Bb, but I don't tell you which is which?
Indeed. My PR is failing some tests as well, and I can't say I'm all that surprised. I knew that this had the potential to cause problems.
Hmm, I think that's a different issue. But iIt seems likely a similar code change to Matt's would be needed somewhere in the layout, where we calculate whether a note needs an accidental or not.
I'm changing the status back to "active" until we have a working PR.
I'd like to add that in 3.6.2 this only seems to happen if you press the flat button after note input and no longer during note input.
IMHO adding both flats if the second one is explicitly asked for after note entry is expected and correct (though to some perhaps unexpected) behavior.
Moving into "needs info" to figure out if there's a different set of steps that do lead to these double flats without the user explicitly asking for them.