Re: fix Issue 2462. (issue 108280044 by address@hidden)

[Janek Warchoł]

Hi,

sorry for delayed reply - i had a busy weekend (been on a wedding!)

2014-07-05 19:46 GMT+02:00 Keith OHara <address@hidden>:
> On Fri, 04 Jul 2014 14:38:19 -0700, Janek Warchoł <address@hidden>
> wrote:
>
>> 2014-07-04 23:26 GMT+02:00 Janek Warchoł <address@hidden>:
>>>
>>>
>>> That's actually not what i want to do; I apologize for being unclear.
>>> I *want* the columns to behave the same way in case of both
>>> accidentals and lyrics (and everything else).  The desired behaviour
>>> is that changing min_distance shouldn't affect ideal distance.
>
>
> Sensible, for the data object Springs.  The special behavior when
> min_distance is larger or within 0.3 of ideal is confusing.  The fact that
> the special behavior appears only after using merge_springs() makes things
> more confusing.

Definitely.

> Notice that frax/springs keeps that special behavior, in Spring::length().
> The natural, force=0, length of a spring is *always* at least
> min_distance+0.3

Yes, and that's intended (see below).  However, there may be a better
way of implementing this - i'm not fully satisfied with how it's done
in frax/springs.

>>> Achieving this [desired, not-special] behaviour when columns arewide due
>>> to lyrics is simple:
>
>> but there
>> are side effects (too tight spacing in some cases, for example in
>> beam-rest-extreme.ly) which i'm unable to fix.
>
>
> Trace back and see what code uses that +0.3 to good effect, though probably
> by accident.
>
> Only spacing-spanner.cc uses Spring::merge_springs(), and when setting
> 'beam-rest-extreme.ly' it is used to 'merge' only one spring!

Interesting, i didn't notice that!

> So one good effect is that accidentals are prevented from getting too close
> to the previous note.  That would be better handled with padding associated
> with the accidental
> <http://code.google.com/p/lilypond/issues/detail?id=3869>

I'm not sure if this actually is what we want.  Padding would mean
that the accidental _never_ gets close to the previous notehead, while
we would acutally want to permit that when the compressing force is
sufficiently large.  So, i think that this has to be done at the level
of springs.

> You could limit the changes in one patch, if you like, by moving the "ideal
> = max(idea, min_distance +0.3)" to the point where spacing-spanner.cc finds
> min_distance to avoid collisions.  A magic number is better than a magic
> number in a mysterious place, and making the 0.3 a parameter is safer to do
> after we narrow down its beneficial effect.
>
> If merge_springs() behaves more simply, it might do a little better for
> <http://code.google.com/p/lilypond/issues/detail?id=3887>
> (I notice that the option 'average-spacing-wishes' is no longer checked; the
> code seems to always average spacing between voices.)

ok - this looks like a good path to follow.  Unfortunately, i don't
know when i'll have enough time to chew on this stuff - it seems that
i'll have a busy week (or two).  Please don't feel ignored if I post a
new alignment-related patch instead of working on this issue - i still
understand alignment code much better than springs, so i can put
togethter an alignment patch in time that would be insufficient to do
anything reasonable with springs.

Anyway, thanks a lot for your comments - i understand the springs
better now.  Sooner or later a patch will be written :)
best,
Janek