Re: Ignore accidentals of the beam itself when guessing an initial configuration. (issue4450052)

[address@hidden]

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

> On Sat, Apr 23, 2011 at 9:28 AM, address@hidden
> <address@hidden> 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