Upper-voice-dotted 2nds positioning issues

• Jul 30, 2019 - 13:09
Reported version
P2 - Medium
S4 - Minor

Screen Shot 2019-07-30 at 13.04.30.png

The 2nd between the soprano E and alto D, the alto D is positioned too far to the right, causing the following problems:

Problem 1:
The D can be selected and Chord X position changed to about -0,60 to correct the problem, but very often simply clicking the lower note (here D) causes MS to hang with a spinning beachball (Mac) and MS must be force-quit and restarted (hence issue reported as S2 Critical, although the hanging is random, not always, it happens more often than not).

Problem 2:
The note following the wrongly positioned note, here the C following the D, cannot be moved to the left. Changing the value of Chord X for the C to a negative value doesn't move it closer to the D, instead it pushes itself and everything left of it to the left, and the spacing remains the same, the measure just gets wider which makes the spacing even worse. The spacing of the 8th notes in the alto looks wrong, and the problem is emphasised by other voices aligning with the D and C, here a tenor voice G# and A. The alto C and tenor A need to move left, but MS apparently makes this impossible. I guess this has to do with automatic placement, but could not find a switch on any element to change this behaviour. I did not open a separate issue for this because it seems to me directly dependent on Problem 1.

The far-right position of the alto D is apparently being calculated as if the dotted upper voice soprano were on a space, as below:

Screen Shot 2019-07-30 at 13.04.54.png

In this case, the spacing is correct, although the alto E is too far to the right and cannot be moved left (see above). MS is erroneously applying this wide spacing to the lower voice for all upper-voice-dotted seconds, resulting in the above explained problems.


Title Upper-voice-dotted 2nds positioning issues (including hang) Upper-voice-dotted 2nds positioning issues
Severity S2 - Critical S4 - Minor
Status active needs info

First, please, attach this score for checking (images are pretty unuseful)

I can recreate the measure, but MuseScore does not hang when I select the D, so for Problem 1 we really do need you to attach the score, like cadiz1 said.

As a workaround for Problem 2, you can select the C and decrease the Segment's "Leading space".

Thanks for the tip on Segment > Leading Space, as a workaround that solves that problem.

These hangs are happing a lot, when selecting notes. I've done a few samples in Activity Monitor during the hang and it appears to be something to do with PortMIDI. My guess is that a MIDI feedback loop is being created somewhere causing this hang from a wide variety of actions. This is probably also the cause of the hang reported in https://musescore.org/en/comment/936894#comment-936894 sorry

As for the layout, what MuseScore does is correct. It is improper for a single dotted note to be separated from its dot by another note, it creates confusion. Only if both notes are dotted is it advisable to place all the dots to the right (in this case, either layout is considered permissible).

In reply to by Marc Sabatella

Nobody suggested that the dot should be moved. The dot on the soprano E is in the right place. The alto voice D is not positioned correctly, it's too far to the right. What MS does here is in terms of the dot appears in all cases correct and nobody said otherwise. In terms of the lower voice the second example is correct and the first example is definitely not correct, and the problem is that MS is following the rule for the second example in the first example which it shouldn't do..

that 2nd example lools exactly like the 1st, as far as the distcance of the notes is concerned
Right, that's what @.function_ has been saying all along. In the first picture, there is room for the D to move closer to the E without changing the position of the dot, because the D is on the space below the dot. This is in contrast to the second picture, in which there is no room for the G to move closer to the A, because the dot is in the way.

I think the OP is clear and I don't want to keep repeating myself. There is nothing about a position of a dot anywhere. It's about the lower note.

Workaround No Yes

Right, you were clear, I just misunderstood because it's a not-uncommon mistake to think note-note-dot would make sense.

Currently, the dot is treated as extending the width of the note - we don't make any allowance for its vertical position, just as you observed. That would be possible in theory, and in fact there are other places where we'd love to make these same sorts of optimizations, but the beaming algorithm ends up getting in the way. See #285591: Accidentals no longer tuck under/over previous notes and the PR I submitted as a work in progress.

In reply to by Marc Sabatella

Good to see there is work in this area. These spacing issues (along with ties clashing with dots) are what I find myself having to spend the most time on to prepare scores for publication. Nevertheless, I'm truly amazed at how well MuseScore works. I spend much less time "fixing" the notation than I had to previously with commercial notation software. So thank you all.