Re: Beam collision push

[address@hidden]

On Feb 24, 2011, at 11:23 AM, Mike Solomon wrote:

> 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?
> 

An example from Bertrand Bordage.  My patch produces the result where the beam 
is compressed to the middle of the staff.  This is, according to him, standard 
practice in Breitkopf et Bärenreiter.  I've also included a version produced 
with the current master, which pushes the beam below the A natural.

My version cannot, however, do this right out of the box in all cases: it 
sometimes needs an override to catch the collision.

Cheers,
MS

organ.ly
Description: Binary data