Re: Beam collision push

[Mike Solomon]

On Feb 24, 2011, at 10:52 AM, Han-Wen Nienhuys wrote:

> On Thu, Feb 24, 2011 at 10:11 AM, Mike Solomon <address@hidden> wrote:
>> Hey all,
>> 
>> Han Wen - I saw that you pushed your beam collision work to master branch.
>> 
>> I truly feel that this is premature and I urge you to undo it.  The reason I 
>> have not pushed my patch yet is because I think more people need to chime 
>> in.  This type of collision avoidance is very important to my current work 
>> as a composer, and the version that you pushed will not be able to correctly 
>> account for several types of collisions, as you saw in the files that I sent 
>> out to the list (unless you have modified it in a way of which I'm not 
>> aware), not least of which are the type that Neil sent out to the list and 
>> that my patch currently deals with.
>> 
>> Collision avoidance is a brute-force manipulation of the beam that is 
>> difficulty to justify in quanting, which should deal with a discrete range 
>> of limited possibilities.  It forces one into a cycle where one has to guess 
>> the appropriate region size to catch large collisions and recompile to see 
>> if one was right.  In doing so, the region size increase invariably 
>> increases the time of compilation.  It also does not allow for fine tuning 
>> of beam collisions on a grob-by-grob basis, which you see in action in the 
>> response I sent out to Neil.
>> 
>> Please, again, I urge you to undo this before people start building on it.  
>> I do not believe that it is a tractable long-term solution, and I feel that 
>> pushing this early kills any dialogue on a better way of going about this.
> 
> Let me cook something for the situations you need as well this
> weekend.  Can you make a .ly with a few realistic samples of what you
> need?

I would need the attached .ly to yield results comparable to the attached PNGs. 
 You can throw in Neil's Debussy example as well (let me know if you need me to 
forward the mail - it was from a couple weeks ago).

I reiterate that I think it is very important to reconsider the approach 
instead of simply fixing the pushed version.  Quanting should be reserved 
solely for the fine-tuning of beams in a position that is already around where 
the beam will lie, not for the moving of beams to another (sometimes far away) 
place as the result of a collision.

I feel that, if you set off to address this issue this weekend with the current 
code, it will result in kludges to the algorithm.  For stacked.ly and solo.ly, 
I believe it will be hard in your to fine-tune the direction of the collision 
avoidance.  Furthermore, in the longer example, it will result in the user 
constantly upping the quanting region to account for the wider collisions, 
which can lead to the type of guessing game that automated notation is meant to 
avoid.  This is because the idea of quanting only makes sense if you are 
confident that the beam that is being passed to the quanting algorithm is 
already in the neighborhood of where it will ultimately lie, which is the core 
feature on which my patch trades.

Again, I urge you to undo this push, study my approach to 37 as thoroughly as I 
have studied yours, and state the exact reason for which you feel that your 
approach makes sense as well as any perceived deficiencies in mine.  You had 
suggested briefly before that a merge may be possible, in which case I'd be 
interested in how you'd see that happening.  I am trying to make the most 
compelling argument possible given the protracted engagement I have had with 
this issue.  So that LilyPond can be the best piece of software it can be, I 
would very much appreciate your doing the same.

Cheers,
MS

37.robust.ly
Description: Binary data

stacked.ly
Description: Binary data

solo.ly
Description: Binary data