Makes parameters for hairpin rotation available in Scheme

[MikeSol, 2011-07-23 14:48:01]

I think that this is sufficient to "fix" issue 36.  As Graham points out in the
tracker, it is difficult to imagine what a good solution is, and I have a
feeling that the solution likely depends upon the user's preferences.  In
certain situations I can see making the hairpin take up less vertical space and
using whiteout, in other situations I can see it being rotated to follow the
slope of the beam.  In either of these cases, in order to know if an
intersection occurs, the hairpin needs to know:

a) The cross staff beams that happen during it.
b) The left and right Y-positions of the beams.
c) The left and right X-positions of the beams.
d) Its own left and right X/Y positions.

(a) is currently impossible to calculate in all circumstances, and (c) would
require a code dup.  I think by making these available as properties, the user
can then use this data to fix the problem.  In the example given in Issue 36, I
would personally rotate the stencil downwards, and this patch would give me all
the data necessary to create an override for Beam #'rotation.

Cheers,
MS

[pkx166h, 2011-07-24 09:34:54]

Make passes but reg test check fails

see my comment: 

http://code.google.com/p/lilypond/issues/detail?id=36#c5

[Neil Puttock, 2011-07-24 21:29:10]

On 23 July 2011 15:48,  <mtsolo@gmail.com> wrote:

> (a) is currently impossible to calculate in all circumstances, and (c)
> would require a code dup.  I think by making these available as
> properties, the user can then use this data to fix the problem.  In the
> example given in Issue 36, I would personally rotate the stencil
> downwards, and this patch would give me all the data necessary to create
> an override for Beam #'rotation.

This is too specific to hairpins.  Most grobs collide with beams when
they're cross-staff, so a more generic solution is required.

Cheers,
Neil

[mike_apollinemike.com, 2011-07-25 08:03:12]

On Jul 24, 2011, at 11:29 PM, Neil Puttock wrote:

> On 23 July 2011 15:48,  <mtsolo@gmail.com> wrote:
> 
>> (a) is currently impossible to calculate in all circumstances, and (c)
>> would require a code dup.  I think by making these available as
>> properties, the user can then use this data to fix the problem.  In the
>> example given in Issue 36, I would personally rotate the stencil
>> downwards, and this patch would give me all the data necessary to create
>> an override for Beam #'rotation.
> 
> This is too specific to hairpins.  Most grobs collide with beams when
> they're cross-staff, so a more generic solution is required.
> 

We may want to just fix issue 36 via something in the docs- you're absolutely
right about the many collisions, and it is easy enough to create a Scheme
engraver that acknowledges beams and spanners and adds cross staff beam to a
grob array of the spanner than can be subsequently accessed to rotate/move/etc. 
Were there one obvious solution to the problem, I'd advocate incorporating it
into LilyPond, but as there is no clear way to deal with these collisions,
perhaps a section in the documentation "Dealing with collisions" that says
something to the effect of "LilyPond does its best to avoid collisions between
objects.  However, often there is more than one solution available to collision
avoidance - white out, moving, rotating, etc..  Rather than taking any one of
these actions automatically, LilyPond provides the user tools to make these
decisions with respect to any given collision."  Then, show the whiteout
solution, custom engraver solution, etc..

Cheers,
MS

[Graham Percival, 2011-07-25 22:22:05]

On Mon, Jul 25, 2011 at 09:17:53AM +0200, mike@apollinemike.com
wrote:
> 
> We may want to just fix issue 36 via something in the docs-
...
>  but as there is no clear way to
> deal with these collisions, perhaps a section in the
> documentation "Dealing with collisions" that says something to
> the effect of "LilyPond does its best to avoid collisions
> between objects.  However, often there is more than one solution
> available to collision avoidance - white out, moving, rotating,
> etc..

sounds good to me.  That's in Learning 4.5 Collisions of objects,
right?

Cheers,
- Graham

[MikeSol, 2011-07-27 08:44:51]

On 2011/07/25 22:22:05, graham_percival-music.ca wrote:
> On Mon, Jul 25, 2011 at 09:17:53AM +0200, mailto:mike@apollinemike.com
> wrote:
> > 
> > We may want to just fix issue 36 via something in the docs-
> ...
> >  but as there is no clear way to
> > deal with these collisions, perhaps a section in the
> > documentation "Dealing with collisions" that says something to
> > the effect of "LilyPond does its best to avoid collisions
> > between objects.  However, often there is more than one solution
> > available to collision avoidance - white out, moving, rotating,
> > etc..
> 
> sounds good to me.  That's in Learning 4.5 Collisions of objects,
> right?
> 
> Cheers,
> - Graham

Yup.
I'm gonna close this Rietveld issue.  Could you downgrade the priority of the
issue on the tracker to either medium or low (depending on what you think would
be appropriate) and add the right tags that show this needs to be a
documentation suggestion (not a code base fix).

Cheers,
MS