Re: collision beam with staff-crossing beam

[address@hidden]

On 13 févr. 2013, at 11:06, Werner LEMBERG <address@hidden> wrote:

> 
>> \override Beam.Y-extent = #'(0 . 10)
>> \override Beam.vertical-skylines =
>>             #ly:grob::simple-vertical-skylines-from-extents
> 
> Nice!  And completely undocumented, of course...

There are currently around 100 callbacks in LilyPond for various properties 
(check out anything in define-grobs.scm starting with ly:).  For most of them, 
there is no way to know how they work unless one reads code.  In the 
documentation build, there is no mechanism to document what these callbacks do. 
 Furthermore, there are several ways to accomplish many things (including the 
task above) and it is not always obvious what the benefits and drawbacks are.

It would be fantastic to have the systematic documentation of all of these 
callbacks in some form of API.  Would you be interested in organizing this?  I 
would be happy to help.

> 
> What I want is something similar: Instead of having a rectangular
> skyline, I want some `padding' (bad word here, I know): If a beam
> looks like this
> 
>      /|
>     /||
>    /||x
>    ||x
>    |x
>    x
> 
> I want to have the top skyline like this:
> 
>      /
>     /
>    / /|
>     /||
>    /||x
>    ||x
>    |x
>    x
> 
> Maybe
> 
>  \override Beam.skyline-offsets = #'(0 . 10)
>  \override Beam.vertical-skylines =
>              #ly:grob::shift-vertical-skylines-by-offset
> 
> Especially for beams with a large slope this might be a better
> approach and usable for many other grobs also, I believe.
> 
> 

This is an excellent idea.  One of my current patches starts a more robust API 
for skylines (the same sorta thing that exists for stencils, allowing to 
translate, etc.).  After that is pushed, I'll expand it to allow this sort of 
thing.  Pester me in 2 weeks or so if I forget.

>    Werner
> 
> 
> PS: Even after looking at lilypond output compiled with
> 
>      -ddebug-skylines='#t'
> 
>    I don't understand what
> 
>      \override Beam.skyline-horizontal-padding = #50
> 
>    actually does.  Can you please explain?

I just did a "git blame" on the docstring...I'd consult with the last person 
who touched it :-)

It is a good docstring but could perhaps be changed to "Fattens each 
constituent building of a skyline by this amount when determining distances 
with other skylines.  The larger this is, the more likely two buildings are to 
be identified as intersecting."

Cheers,
MS