On Feb 10, 2011, at 7:50 AM, Han-Wen Nienhuys wrote: > On Thu, Feb 10, 2011 at 9:54 AM, [email protected] > <[email protected]> wrote: > >> I think that the problem with doing the collision avoidance in the quanting >> reveals itself around line 341 of beam-quanting.cc >> if (collisions_.size ()) >> region_size += 2; >> Here, I get the sense that you are expanding the region size of the quanting >> if there is the possibility of collision. I feel that this will actually >> work against the goal that you had previously set: namely, to avoid >> unnecessary quants if possible. By moving the beam out of the collision > > On the contrary: avoiding unnecessary quants for normal cases makes it > possible for us to use brute force on exceptional situations like by > knees of collisions.
OK - I see what you mean, but I'd have to follow it in the code better. Where does this happen? > >> region before the quanting (in beam.cc, for example), which would do similar >> stuff to that which you have written around line 151, you would eliminate >> having to expand the region size and you'd be able to catch problems that >> your code doesn't currently catch. That said, your code does catch a great >> deal of stuff - I ran 10 or so tests against the algorithm and not many of >> them diverged (those that did are attached, prefixed ms or mike for me and >> hw for you). > > I only see one page in both pdfs? If you can send me code as .ly, I > can add them to the my regtest, to have more cases. I'll try my best to have this done by tomorrow night (frantically composing!) > >> However, those that did diverge do come up in actual rep - >> what worries me is that your code (as I understand it) cannot, by virtue of >> how its made, catch several examples from the contemporary repertoire that I >> threw up on that website (notably the Boulez and Crumb) without increasing > > I don't see anything by Crumb. The boulez example is actually a > straight flag (left), and a beam with normal stem on the left. > I don't have the link and password handy, but I remember that I was thinking of the boulez as an unfinished beam. You're right that the actual example is a straight flag, but if someone did that with a beam, it'd be fair game for collision avoidance. You're right about the crumb (I have that snippet on my Desktop & am looking @ it now) - that is a mistake on my part. I'll go back on Sunday and see if I can find the actual collision. >> the region size to something very large. >> I still advocate the solution in http://codereview.appspot.com/4131044 for >> all the reasons I mention above: I feel that it actually takes less time by >> never expanding the region size and can catch more results. >> Mostly, I think that having two developers doing more or less the same thing >> is a potential waste of time. My understanding of Lilypond is many orders >> of magnitude inferior to yours, and I assumed (and am still assuming) that >> your work on this problem is addressing an issue that I fundamentally don't >> get. My critique above still stands, which I why I am still advocating my >> code, but it could be that with a couple tweaks, your code could address >> those issues as well. > > My criticism centers on > > + if ((pressure[UP] > 0) && (pressure[DOWN] > 0)) > + { > + warning ("Cannot resolve beam collision."); > + return posns; > + } > > ie. if you are dealing with polyphonic music, where the middle voice > will have notes under and over it, your technique does not work. > I don't think that bit of code does what you think it does. From my technique:
<<inline: mike-complex.png>>
That's the best I can do in polyphonic stuff. I think it addresses your concern. > That said, there may be place for both techniques: if you could detect > that a note+stem is pushing the beam far out of its original position, > you could add an offset. This offset adding code could be very dumb, > because the fine points of finding the best solution will be handled > by the beam quanting anyway. I completely agree - I feel that my solution does exactly this (adds a general offset that is fine tuned in the quants). Read it over again if you get the chance - do you think that it adequately addresses the polyphonic concern you have? > >> Cheers, >> MS >> <hw-37robust.pdf> >> <hw-beam-collision.pdf> >> <hw-complex.pdf> >> <hw-full-beam-collision.pdf> >> <mike-beam-collision.png> >> <mike-complex.png> >> <mike-up-down.png> >> <hw-beam-collision-beamcount.pdf> >> <ms-beam-collision-beamcount.pdf> >> <ms-37robust.png> > > I only received 2 pdf files, was that intentional? > > -- > Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen
_______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
