Re: Issue 37 - new work

[Mike Solomon]

On Jan 28, 2011, at 6:12 PM, Mike Solomon wrote:

> On Jan 28, 2011, at 1:15 PM, Han-Wen Nienhuys wrote:
> 
>> pressed send too soon.
>> 
>> On Fri, Jan 28, 2011 at 4:14 PM, Han-Wen Nienhuys <address@hidden> wrote:
>>> On Fri, Jan 28, 2011 at 11:22 AM, Mike Solomon <address@hidden> wrote:
>>>> 
>>>> I cooked up this musical example that shows both responses to upward and 
>>>> downward pressure to give you an idea of where I'm coming from.
>>>> 
>>>> Is there a way to get this type of collision avoidance w/o a 2nd quanting 
>>>> pass?
>>> 
>>> You are now dramatically extending the problem scope: you are looking
>>> for a configuration that optimizes configurations of all beams at the
>>> same time.  For example, it is conceivable that individually, the beam
>>> for A below staff would be better served when the beam goes up the
>>> line of D''.  However, that would leave no room for the A' beam, since
>>> it would be on top of the A'' beam.
>>> 
>>> A solution that would work for this should optimize all of the beams
>>> at the same time.  It might be feasible to code, but probably only if
>>> you restrict all the beams to be
>> 
>> horizontal.  The tie formatting is similar: it also tries to find a
>> configuration where *all* ties between a chord are more or less OK.
>> 
> 
> I've made an updated version where the collision penalty controls the extent 
> to which the beam approaches the original quants.  In the png below, the 
> penalty is set normal first, then insanely high.
> "Normal" builds the regtest to look as pretty as possible but fails in tight 
> situations like the first example in the png.  If you set it too high, it 
> leads to the non-conventional quanting in the second example.  That said, I 
> think that most users would opt for ugly quanting over smooshed beams and 
> thus go w/ the second example.
> 
> Interestingly, if you comment out the slope damping function, it leads to 
> even better results for the inner two beams, leading me to believe that there 
> should be a switch that allows one to bypass this function.
> 
> Perhaps that should be a separate patch, though.  Thoughts?
> 
> http://codereview.appspot.com/4022045
> 

Clean make check.
http://codereview.appspot.com/4022045

Cheers,
MS