Dot placement in voices 2 an 4 erratic.
For dotted notes in voice 2 and 4, the dot is placed below the lines when the notehead is on a line.
This is incorrect. The dots should always be above the line, regardless of voice.
When this happens in a chord, some notes in a dotted chord looks as if the dot is missing because
it coincides with a dot in another voice that is set above the line.
Comments
Seems related to #45576: Tie on same side of staff/ledger line as augmentation dot = collision and also #177831: Nonstandard (possibly insufficient number or incorrect placement of) augmentation dots for certain chords
Can you post a specific score where you are seeing an issue? In general, your original statement that dots should always be above the line regardless of voice is incorrect - the standard rules of engraving include many situations where the dots go below. See for instance Gould p. 56: "Double stems / Lower part on a line: Drop the dot into the space below the lower part".
MuseScore tries to follow standard rules as well as it can, but there some cases involving multiple voices and/or complex clusters where you can indeed see fewer dots than notes, and this is not correct. MuseScore 4 fixes some but probably not all of these cases, so it would be important to see your specific example in order to understand if it's already fixed.
Meanwhile, you can flip the dots manually using the Inspector. Note, though the solution is almost never to force all dots above - that normally makes the problem worse. The solution is normally to be more clever about which go above and which below.
In reply to Can you post a specific… by Marc Sabatella
There is an example: https://musescore.org/en/node/177831
The problem is that one dot is set below and the other above and so they are printed at the same place.
If one selects the dots and specifies instead of automatic 'above' or 'below' for all notes of the chord, then you can see all.
BTW: this is not depending from the choosen voices, you can find it also if you create an chord only in voice 1.
In reply to There is an example: https:/… by HildeK
That's not the same as what you're asking about, though - that's all a single voice. And yes, in such cases, if there are seconds involved, it definitely is necessary at times to alternate above/below for dots. Putting them all above is a recipe for problems for sure, and that's exactly why the chords shown in that example fail - MuseScore isn't being smart enough to figure out which need to go below. In the first chord - C-E-F-A - the E and C both need to go below. MuseScore figures that out for E, but fails to notice it also needs to move it below for C.
Moving them all above "works" but produces much worse results - you end up with the dot for the top A a full space above the note. That should be a last resort for tight clusters, not a simple chord with a single second.
So again, some dots need to go below in order to avoid these problems. The norm in published music and in MuseScore is to do this automatically for downstem notes, and then for chords containing seconds, to try to sort out the best approach and just do whatever works. I think MuseScore 4 improves on 3.6.2 in some ways, but it still fails to move the dot for the C down in that first case.
OK. I won't argue with Elaine Gould. There are likely to be reasons to put the dots below the line.
After reading the other thread about this, and finding that there is a suggestion as to how to fix the
auto algorithm, I'm surprised that this hasn't been changed already.
Nevertheless, I'm posting a dead simple score to show my point. Play with the pitch of the different notes and watch what happens.
In reply to OK. I won't argue with… by bernerus
Yes, as already mentioned, it’s known that the current algorithm doesn’t handle clusters that well. I was just confused by your original post, which suggested there was also a problem involving multiple voices specifically. So that’s what I was looking for an example of - a case where there was a problem specifically caused by multiple voices as opposed to seconds. But I’m pretty sure any issues you are encounter are caused by the seconds, not the voices, in which case they are indeed known problems.
In reply to Yes, as already mentioned,… by Marc Sabatella
That is probably correct, although if, as somebody mentioned, there are different defaults for different voices, and that default goes as an input to the placement algorithm, then the phenomenon may be more likely to occur if different voices are involved.
However, I was hit by this when I used different voices, but I admit that I did not test this using
a single voice at the time, but now I have tested this, and indeed, the same chord given to a single voice renders as expected, but with voice 2 on an E and voice 3 on a C, the dots clashes (regardless of stem direction btw).
-- Chris
In reply to That is probably correct,… by bernerus
Right, the dot algorithm uses the voice number to guess the stem direction rather than actually using the stem direction for some reason - not sure if there was some specific use case where this was desired. It would not normally happen in regular usage, though. But if you do have a case where using multiple voices to "fake" a chord, and you are also using the "wrong" voices and then forcing opposite stem directions, you might also have to override dot positions currently.
Again, I'm not sure if there was a real-world use case that prompted the decision to base dot position on voice number rather than actual stem direction. But if there is a real-world use case for what you're doing in these examples, and it turns out to be more common than whatever real-world use case might have prompted the original decision, it could certain be revisited.