On May 5, 2011, at 2:12 AM, Nick Payne wrote:
> On 05/05/11 13:21, m...@apollinemike.com wrote:
>> On May 4, 2011, at 3:16 PM, Nick Payne wrote:
>>
>>> Latest LP development version has inconsistency. See below.
>>>
>>> \version "2.13.61"
>>>
>>> \relative c'' {
>>> \time 3/4
>>> \key d \minor
>>> <<
>>> {<e bes>8 r<e a,> r s }
>>> \\
>>> { d, r cis r r4 }
>>> \\
>>> { g'8. f16 g8. bes16 a8. g16 }
>>> }
>>>
>> The disparity in results comes (I think) from the fact that the flag of the
>> stem in the left example ends after the beam begins on the X axis, and thus,
>> the beam collision engraver moves the beam up to avoid the entire stem+flag.
>> In the second example, on the other hand, the flag's rightmost X point
>> falls to the left of the beam's leftmost X point.
> Yes, that seems to be why, as if I add \once \override NoteColumn
> #'force-hshift = #1 at the beginning of voice 2, then both beams intersect
> the rests above. However, if the collision avoidance mechanism does shift the
> note at the beginning of voice 2 horizontally, why doesn't it shift the note
> far enough for the stem/beam to avoid the flag on the note in voice 1, given
> that it manages to do so successfully for the second beat in the bar. Or is
> that difference due to the notes in the two voices being a third apart on the
> first beat but only a second apart on the second beat.
>
Hey NIck,
Not to get too technical (but I'm gonna get too technical), the mechanism that
decides the X placements of grobs (and thus the bleed-over of stems into a
beam's X extent) does not have anything to do with LilyPond's beam collision
algorithms. You'd want to report two separate bugs: one about the fact that
the horizontal shift of the stem is inconsistent, and one that the
beam-collision-engraver kicks in for even minuscule overlaps in grobs'
X-extents.
In this instance, if you put \once \override Beam #'collision-voice-only = ##t
before the first beam, you're golden. Meanwhile, I'm working on something for
the next devel version that gets beams to avoid rests.
Cheers,
Mike
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
