Beam collision scoring

Beam collision scoring

* Add separate scorer for horizontal inter quant

* Split up slope scorers

* Add collision precompute data and scoring pass

* Add separate factor for lighter penalties of stem/beam collisions

* Further decrease debug data fontsize

* Add different testfiles.

[Keith, 2011-02-10 07:02:17]

I tried this patch on half a dozen piano and orchestral scores and saw no bad
side-effects.

Only manual [] beams are checked for collisions. I cannot remember why this is
so, and could not find the reason in the email archive.  The collision avoidance
looks good for all beams, if possible.

I checked that manual beams do indeed avoid the things on the list in the
previous commit for beam_collision_engraver :
(note_head); (accidental); (clef); (key_signature);(time_signature); (bar_line);
(beam);

Bar lines should probably not be counted for collisions.  Certainly intersecting
a bar line is less of a demerit than crossing a stem.  The only reference I have
at hand (Kurt Stone) says nothing to this question, unfortunately.  

In any event, the current patch allows beams to intesect the cross-staff portion
of a bar line, so my piano example
(http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1779) came out just
fine.

http://codereview.appspot.com/4174043/diff/2001/input/regression/beam-collisi...
File input/regression/beam-collision-prefatory-matter.ly (right):

http://codereview.appspot.com/4174043/diff/2001/input/regression/beam-collisi...
input/regression/beam-collision-prefatory-matter.ly:25: \key f \major
suggest \bar "||" before \key, so the humans checking regtests recognize these
as key changes.

[Keith, 2011-02-10 07:21:31]

On 2011/02/10 07:02:17, Keith wrote:
>
> (note_head); (accidental); (clef); (key_signature);
> (time_signature); (bar_line); (beam);
> 
I forgot to ask the question that prompted me to look this up.
Why not avoid collisions with rests as well ?

[Keith, 2011-02-10 07:44:50]

On 2011/02/10 07:21:31, Keith wrote:
>
> (note_head); (accidental); (clef); (key_signature);
> (time_signature); (bar_line); (beam);
>
Actually, beams do not avoid other beams like I thought they might.  I cannot
think of a way this would come up in natural music, but since it seem you tried
to catch beam-beam collisions, I should point out :
\relative c' << { e8[  c] } \\ { r16 b''8[ b] } >> 
\relative c'' { f8^[ \grace { e16[ g] } e8] }

and if you want to consider catching collisions with rests, 

\relative c'' << { a8[ f] } \\ { r16 g'8\rest r16 } >>

[hanwenn, 2011-02-10 12:27:25]

2011/2/10 Werner LEMBERG <wl@gnu.org>:
>
>> I tried this patch on half a dozen piano and orchestral scores and
>> saw no bad side-effects.
>
> The attached image (from
> IMSLP00014-Beethoven__L.v._-_Piano_Sonata_14.pdf) shows another
> solution �#| smaller beams �#| to avoid the crossing of beams and stems.
> Maybe this can be implemented too?

The problem is that this requires another layer of code.  The
collision code works for beams individually.  For this to be resolved
like this,  there needs to be coordination between the two beams.
This is much harder, because many such collisions may be chained
together, eg.

<<
   { s8 c[ c] c[ c] s8 } \\
   { c[ c] c[ c] c[ ] }
 >>

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[wl_gnu.org, 2011-02-10 12:45:14]

> The problem is that this requires another layer of code.  The
> collision code works for beams individually.  For this to be
> resolved like this, there needs to be coordination between the two
> beams.  This is much harder, because many such collisions may be
> chained together, eg.
> 
> <<
>    { s8 c[ c] c[ c] s8 } \\
>    { c[ c] c[ c] c[ ] }
>  >>

Hmm.  What about adding some commands to restrict such collosion
resolution horizontally?  I'm quite sure that most of the problems are
local, and the user knows in advance where it happens so that it can
be tagged with, say, \startFullBeamCollisionHandling and
\stopFullBeamCollisionHandling.


    Werner