too much space after barline in measure with accidental and multiple voices

• Feb 12, 2014 - 05:34
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
layout
2.0

Windows 7, GIT commit: 9fd8764

1) create new score
2) click any measure, enter note input mode
3) enter quarter note C# in voice 1
4) enter quarter note G in voice 2

Result: the C# move to the right upon entry of the G.

MuseScore does a good job of placing an initial accidental close to the left barline if there is only one voice. But as soon as you enter something into another voice, MuseScore adds more space unnecessarily.

Pointed out by Janek Warchol as a result of the LilyPond engraving challenge - see http://engravingchallenges.freeforums.org/submission-3-musescore-2-0-de…

EDIT: I originally wrote I thought it might be OK to downgrade this to "minor", but it *is* a regression versus 1.3, and I do think it's relatively significant as these things go. It's not just a few pixels, but about a full spatium off. Makes for some noticeably inconsistent spacing within a score .

Comments

• Mar 9, 2014 - 06:53
Status (old) closed ⇒ active

The case of voice 1 with accidental is fixed, but there is still too much space if voice 1 has no accidental but voice 2 does. The code in Measure::layoutX() sets minDistance to barNoteDistance on the first pass (for voice 1) and thus even if other voices have accidentals, it never gets lowered to barAccidentalDistance on subsequent passes, both because accidentalStaff is preventing the check for accidentals in other voices, but also because in the call to qMax, barNoteDistance will win every time.

I've got a tentative fix for that much, but there's more. If voice 2 is only a second below voice 1, adding an accidental to voice 2 results in much more than barNoteDistance being added (the below shows the result without my fix):

acc-space.png

Of course, the accidental is also placed incorrectly here, but I have a fix for that too (see https://github.com/MarcSabatella/MuseScore/commit/5b4bd951033f800d3a496…). Even with both of these fixes in place, there is too much space, but so far, I am not understanding where it is coming from.

acc-space-3.png

Attachment Size
acc-space.png 1.11 KB
acc-space-3.png 1.12 KB

Reply

• Mar 14, 2014 - 01:09

One more thing: seems a similar thing should work for measures beginning with a time signature, not just with a barline. I realize there is no separate parameter for this now, and perhaps there needs to be, as you might not want accidentals quite so close to a signature as to a barline.

Reply

• Mar 22, 2014 - 17:19

I investigated a bit, and it's not trivial...
The addition of space before is due to the Chord "space" set here
https://github.com/musescore/MuseScore/blob/e430b8d85c2a501d907861b18c7…

This space is computed for each chord, and then we take the max for a segment. For each chord, it's done in Chord::layoutPitched(). The specific issue here is with accidental: https://github.com/musescore/MuseScore/blob/e430b8d85c2a501d907861b18c7…

I'm not sure how the accidental position relative to the chord is an indication on how it should be spaced in the measure. It's more the accidental position relative to the segment that should be taken into account (?)

Reply

• Mar 22, 2014 - 20:00

FWIW, the partial fix I had worked out involved only "minDistance", not "space". I guess that's why it didn't always work. I suppose I'd take a partial fix over nothing.

That calculation in chord.cpp does look off to me at first glance, too. As far as I know, accidental "x "positions are calculated relative to the segment, or maybe to the leftmost chord in the segment/staff. So adding accidental->x() and note->x() does indeed seems wrong. Second, accidentalDistance doesn't really have anything to do what is going on here. That's the distance between accidentals, which comes into play only when there are multiple accidentals.

Reply