Re: Broken beams' slopes

[David Kastrup]

Mike Solomon <address@hidden> writes:

> On Aug 24, 2011, at 5:42 PM, David Kastrup wrote:
>
>> Mike Solomon <address@hidden> writes:
>> 
>>> I'll be leaving on vacation in a week-ish, and as my summer-of-lily
>>> comes to a close, I can likely do one more medium-scale thing before I
>>> have to start correcting parallel fifths.
>>> I'd like to work on broken beam slopes such that a beam can break
>>> across lines and pick up where it left off at the same slope and
>>> y-offset
>> 
>> The problem I see with this approach is that one does not, in general,
>> want the same slope and y-offset because it does not make sense to view
>> the broken beam as a single visual entity.
>
> See the attached chords2.pdf versus chords.pdf.  In chords.pdf, I use
> an override to make all beams flat.  In chords2.pdf, I remove this
> override and let lily run her course.  I think that, in chords2.pdf,
> the disparity in slopes across line breaks makes for really ugly
> typsetting.

Agreed.

> I would much rather have long stems and continuity than more even
> stems and divergent slopes.

But the continuity demands are less stringent across the break.  You can
fuzz with beam slope somewhat (things should likely stay rising,
straight, or falling, but the degree is likely more flexible than
without a break), and you can fuzz quite a bit with y position when
needed before you get negative returns.  Of course, without a good
reason there is no point to change either.  Being able to keep them
identical is a good start.  I am just pointing out that it is not the
optimum, and one should likely not try to lose sight of the optimum
entirely, even if it may not make it into code right away.

>> That means that if the unbroken beam would have a _knee_ at the
>> break, you would, when splitting it, tend to prefer _unkneed_ beams
>> with similar slope, even though that would mean a significant jump in
>> y-offset.
>
> Agreed.
>
>> But that makes the visual connection easier to make than a jump in
>> beaming direction.
>
> Agreed.
>
>> So the aesthetic decisions need to work under different constraints
>> than in the unbroken case.
>
> Agreed.
>
>> We have the same "almost, but not quite as if unbroken" situation
>> with slurs and ties.  And it does not just occur with line breaks,
>> but also in connection with repeats and da capo.
>
> True, but I think these grobs are different because they hover over or
> under early columns like clefs and key signatures, whereas beams start
> after these columns.  This allows beam continuity to be a lot better,
> as it does not have to compete with the presence of a giant clef at
> the beginning of the barline that would cause its y-offset to be very
> high or low.

Agreed.  I guess we are in violent agreement.  Just wanted to be sure
that this point was not accidentally overlooked completely, possibly
making things harder to do better at a later point of time.

>> Do we have a sound general strategy for tackling this sort of
>> controlled discontinuity?  Maybe it would be worth thinking about.
>> 
>
> Not really, although I'm way for this (my vector graphics spanner does
> this sorta thing).
>
> I think implementing this type of continuity for beams may be a good
> test case from which a general strategy (if appropriate) can be
> extrapolated and applied elsewhere.

Thanks for keeping an alert mind.

-- 
David Kastrup