Re: Gets vertical skylines from grob stencils (issue 5626052)

[address@hidden]

On 4 juil. 2012, at 15:17, Janek Warchoł wrote:

> On Wed, Jul 4, 2012 at 11:31 AM, address@hidden
> <address@hidden> wrote:
>> Thanks Janek!  Very valuable stuff.
> 
> :)
> 
>>> (sorry, too big for an attachment - 200 kB)
>>> In short:
>>> - staffswitch lines are broken
>> 
>> This is because VoiceFollower is not set as (cross-staff . #t) in 
>> define-grobs.scm.  I'm not sure why...this seems like a good idea 
>> irrespective of how the skyline work pans out.
> 
> I find it even more surprising that Glissandos work perfectly.  Aren't
> they related to VoiceFollowers?

They're set to cross-staff when they are cross-staff, but VoiceFollowers are by 
definition always cross staff.

> 
>>> - some ties change shape
>> 
>> This will take me some time to figure out...I'm gonna have to look at all 
>> the parameters going into tie scoring and see which ones are changing.  I'll 
>> likely push something to staging the weekend or next week in the style of 
>> Tie_formatting_problem::spew () that gives tons of specs and then run the 
>> output through python to pick up on changes.  Of course, if any tie gurus 
>> have intuition about this, lemme know!
> 
> No idea when i'll have time to finish Tie Report, but as tie shapes
> are screwed in general, i wouldn't care much about this change.  New
> shape isn't worse than previous one, i'd say.

I think that there's supposed to be a bit of space in there, no?  What does 
Gould say?
What's important is to figure out why this change is happening.  As ties only 
ever use Skylines made from boxes (and not from stencil integrals), there must 
be some weird subtlety about spacing somewhere (or perhaps the new Skyline 
code) that is causing this.

> 
>>> - some skylines are really weird
>> 
>> This is likely a directioning problem - all upwards pointing skylines seem 
>> to come out just fine.  The culprit would most likely be in 
>> stencil-integral.cc: the notion of "UP" must be hardcoded somewhere that it 
>> shouldn't be.
>> If you have a moment to test out weird-skylines.ly on different versions of 
>> the patchset, I'd appreciate it!
> 
> Tenuto skyline seems to be wrong since the beginning - i've tested
> patchsets 36, 34, 32 and 30, it looked similar everywhere.
> Sharp and forte skylines seemed ok in patchset 36, see here:
> http://lilypond-stuff.1065243.n5.nabble.com/file/n5705595/weird-skylines_patchset-36.pdf
> http://lilypond-stuff.1065243.n5.nabble.com/file/n5705595/weird-skylines_patchset-37.pdf

The tenuto is important, then.  There must be something about it (maybe its 
symmetry) that confuses the the code.  The sharp and forte are also funky...it 
seems that certain regions may have too short estimations.  I'll investigate.

> 
>>> - sometimes objects interlock too much.
>> 
>> This was the case in the lyric example you sent.  I fixed it by adding light 
>> skyline-horizontal-padding to lyrics.
> 
> Hmm.  I have another idea, which would be more difficult but also
> extremely awesome, and it would be very handy for area spacing (see
> http://lists.gnu.org/archive/html/lilypond-devel/2012-03/msg00507.html):
> make the skyline shape "magnetic".  See illustration here:
> http://lilypond-stuff.1065243.n5.nabble.com/file/n5705595/magnetic_skylines_demo.pdf
> 
> What do you think?

It wouldn't be too bad from a coding perspective. The function deholify already 
does this for single skylines: try the skyline of a large font-size string "f   
_   f" or something like that and the holes should be plugged with a sloped 
building.

When there are multiple grobs involved, what becomes tricky is knowing which 
ones should allow for snug-fitting and which ones not.  I think that, as time 
goes on, we'll realize where the snug spacing is too close and will modify it 
w/ padding values.

Cheers,
MS