On Thu, Feb 24, 2011 at 10:11 AM, Mike Solomon <mike...@ufl.edu> 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? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
