Ignore accidentals of the beam itself when guessing an initial configuration.

Ignore accidentals of the beam itself when guessing an initial configuration.

Fixes #1613.

[MikeSol, 2011-04-22 21:20:47]

http://codereview.appspot.com/4450052/diff/1/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4450052/diff/1/lily/beam.cc#newcode1221
lily/beam.cc:1221: 
This solution doesn't work for:


\new Staff {
 <<
   { \voiceOne s16 fis'' }
   \\
   { \voiceTwo e4 e }
   \\
   { \voiceFour
   f''8 e'' gis'' gis'' }
>>
}

One interesting thing is that it is the stems, not the noteheads, that are
pushing this down.  If you remove stems from the beam-collision-engraver, this
problem does not arise.  Why would stems do this but not note heads?

[hanwenn, 2011-04-23 03:29:39]

On Fri, Apr 22, 2011 at 6:20 PM,  <mtsolo@gmail.com> wrote:
>
> \new Staff {
>  <<
>   { \voiceOne s16 fis'' }
>   \\
>   { \voiceTwo e4 e }
>   \\
>   { \voiceFour
>   f''8 e'' gis'' gis'' }
>
> }
>
> One interesting thing is that it is the stems, not the noteheads, that
> are pushing this down.  If you remove stems from the
> beam-collision-engraver, this problem does not arise.  Why would stems
> do this but not note heads?

The problem is that the initial guess for the configuration has two
choices: over all 'big' collisions, and below the big collisions.  The
separate high note adds a collision that is impossible to pass from
the top, so we revert to the bottom.


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

[mike_apollinemike.com, 2011-04-23 12:28:32]

On Apr 22, 2011, at 11:29 PM, Han-Wen Nienhuys wrote:

> On Fri, Apr 22, 2011 at 6:20 PM,  <mtsolo@gmail.com> wrote:
>> 
>> \new Staff {
>>  <<
>>   { \voiceOne s16 fis'' }
>>   \\
>>   { \voiceTwo e4 e }
>>   \\
>>   { \voiceFour
>>   f''8 e'' gis'' gis'' }
>> 
>> }
>> 
>> One interesting thing is that it is the stems, not the noteheads, that
>> are pushing this down.  If you remove stems from the
>> beam-collision-engraver, this problem does not arise.  Why would stems
>> do this but not note heads?
> 
> The problem is that the initial guess for the configuration has two
> choices: over all 'big' collisions, and below the big collisions.  The
> separate high note adds a collision that is impossible to pass from
> the top, so we revert to the bottom.
> 

\new Staff {
 <<
   { \voiceOne s16 \grace fis'' }
   \\
   { \voiceTwo e4 e }
   \\
   { \voiceFour
   f''8 e'' gis'' gis'' }
>>
}

Even with a small high note (see above) the problem kicks in.
If you want, I have some time next week to put in printf's and see what the
exact numerical cutoff is for picking the lower solution.  My first commitment
is to have a look @ Janek's flag code, and then I can look over the beam code.

Cheers,
MS

[hanwenn, 2011-04-24 00:33:19]

On Sat, Apr 23, 2011 at 9:28 AM, mike@apollinemike.com
<mike@apollinemike.com> wrote:

>>>
>>> One interesting thing is that it is the stems, not the noteheads, that
>>> are pushing this down.  If you remove stems from the
>>> beam-collision-engraver, this problem does not arise.  Why would stems
>>> do this but not note heads?
>>
>> The problem is that the initial guess for the configuration has two
>> choices: over all 'big' collisions, and below the big collisions.  The
>> separate high note adds a collision that is impossible to pass from
>> the top, so we revert to the bottom.
>>

> Even with a small high note (see above) the problem kicks in.
> If you want, I have some time next week to put in printf's and see what the
exact numerical cutoff is for picking the lower solution.  My first commitment
is to have a look @ Janek's flag code, and then I can look over the beam code.

The real solution is to work with a list of intervals rather than just
an up/down choice.  I think the simple quick solution is to disable
stems for beam collisions for now.

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

[mike_apollinemike.com, 2011-04-24 00:46:04]

On Apr 23, 2011, at 8:33 PM, Han-Wen Nienhuys wrote:

> On Sat, Apr 23, 2011 at 9:28 AM, mike@apollinemike.com
> <mike@apollinemike.com> wrote:
> 
>>>> 
>>>> One interesting thing is that it is the stems, not the noteheads, that
>>>> are pushing this down.  If you remove stems from the
>>>> beam-collision-engraver, this problem does not arise.  Why would stems
>>>> do this but not note heads?
>>> 
>>> The problem is that the initial guess for the configuration has two
>>> choices: over all 'big' collisions, and below the big collisions.  The
>>> separate high note adds a collision that is impossible to pass from
>>> the top, so we revert to the bottom.
>>> 
> 
>> Even with a small high note (see above) the problem kicks in.
>> If you want, I have some time next week to put in printf's and see what the
exact numerical cutoff is for picking the lower solution.  My first commitment
is to have a look @ Janek's flag code, and then I can look over the beam code.
> 
> The real solution is to work with a list of intervals rather than just
> an up/down choice.  I think the simple quick solution is to disable
> stems for beam collisions for now.
> 
> 

If you're confident that the problem will only be caused by stems and not clefs,
time signatures, etc., I'll do it.  Otherwise, I think it'd be worth it to work
on the list-of-intervals solution.  Otherwise, beams won't avoid grace note
stems, which is the whole reason the stem code was added.

Cheers,
MS