Re: Broken beams' slopes
W dniu 27 sierpnia 2011 15:51 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 8/27/11 7:44 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. I would expect this to yield mostly reasonably results. I'd also keep beam orientation. But it might make sense to dole out a bit of spring force (just decidedly less than infinite) for making the vertical beam positions at the break match. It would seem that this algorithm would fail for a simple broken beam a8[ b \break c f] Care to elaborate? The a to b beam would have a slope of 1 ss per eighth note. The c to f beam would have a slope of 3 ss per eighth note. the a to f beam would have a slope of 5 ss per 4 eighth notes, or 1.2 ss per eighth note. If you choose the slope of 1.2 for both sides, then it seems to me that the b stem will be longer than it would be without the beam on the other side of the break, and the c stem would be longer than it would be without the beam on the other side of the break. If you force the b and c stems to be the same length, the a and f beams would be too short. Sorry, Carl, but i don't get it at all. (btw, in which octave is your example?) Why c to f beam would have a slope of 3 ss per eighth note.? f notehead is only 1.5 ss higher than c, and beams are usually damped, so the beam slope in c[ f] is less than 1.5 ss. Perhaps i didn't explain my suggestion clear enough. Please take a look at the attachment - that's how i imagine beam breaking could work: - first, imagine an unbroken beam. - break the beam while retaining the slope. - adjust them a bit vertically: in the lower octave beam (left side) the notes before the break have a bit long stems, but they couldn't be shorter because beam must stop at middle line. Notes after break have too short stems - these can be adjusted by moving the beam up about 0.5 ss. On the right side, stems before break are quite ok, and stems after the break can be shortened a bit by moving the beam up. I don't see how this could fail or produce bad output - ? cheers, Janek attachment: broken beams.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
On 8/28/11 3:52 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: W dniu 27 sierpnia 2011 15:51 użytkownik Carl Sorensen c_soren...@byu.edu napisał: The a to b beam would have a slope of 1 ss per eighth note. The c to f beam would have a slope of 3 ss per eighth note. the a to f beam would have a slope of 5 ss per 4 eighth notes, or 1.2 ss per eighth note. If you choose the slope of 1.2 for both sides, then it seems to me that the b stem will be longer than it would be without the beam on the other side of the break, and the c stem would be longer than it would be without the beam on the other side of the break. If you force the b and c stems to be the same length, the a and f beams would be too short. Sorry, Carl, but i don't get it at all. (btw, in which octave is your example?) Why c to f beam would have a slope of 3 ss per eighth note.? Oops -- I did all my calculations in half-staff-spaces, so each number should be divided by 2. f notehead is only 1.5 ss higher than c, and beams are usually damped, so the beam slope in c[ f] is less than 1.5 ss. Perhaps i didn't explain my suggestion clear enough. Please take a look at the attachment - that's how i imagine beam breaking could work: - first, imagine an unbroken beam. - break the beam while retaining the slope. - adjust them a bit vertically: in the lower octave beam (left side) the notes before the break have a bit long stems, but they couldn't be shorter because beam must stop at middle line. Notes after break have too short stems - these can be adjusted by moving the beam up about 0.5 ss. On the right side, stems before break are quite ok, and stems after the break can be shortened a bit by moving the beam up. I don't see how this could fail or produce bad output - ? I misunderstood your suggestion. When you said the stems would be the same length as if the other beam were not there, I was not thinking of adjusting the beam quanting only. I agree that your proposal should produce good output. I'm sorry for the noise. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
Janek Warchoł janek.lilyp...@gmail.com writes: I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. I would expect this to yield mostly reasonably results. I'd also keep beam orientation. But it might make sense to dole out a bit of spring force (just decidedly less than infinite) for making the vertical beam positions at the break match. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
Carl Sorensen c_soren...@byu.edu writes: On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. I would expect this to yield mostly reasonably results. I'd also keep beam orientation. But it might make sense to dole out a bit of spring force (just decidedly less than infinite) for making the vertical beam positions at the break match. It would seem that this algorithm would fail for a simple broken beam a8[ b \break c f] Care to elaborate? Or am I missing something? No idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
On 8/27/11 7:44 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. I would expect this to yield mostly reasonably results. I'd also keep beam orientation. But it might make sense to dole out a bit of spring force (just decidedly less than infinite) for making the vertical beam positions at the break match. It would seem that this algorithm would fail for a simple broken beam a8[ b \break c f] Care to elaborate? The a to b beam would have a slope of 1 ss per eighth note. The c to f beam would have a slope of 3 ss per eighth note. the a to f beam would have a slope of 5 ss per 4 eighth notes, or 1.2 ss per eighth note. If you choose the slope of 1.2 for both sides, then it seems to me that the b stem will be longer than it would be without the beam on the other side of the break, and the c stem would be longer than it would be without the beam on the other side of the break. If you force the b and c stems to be the same length, the a and f beams would be too short. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
Carl Sorensen c_soren...@byu.edu writes: On 8/27/11 7:44 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: I wonder if this solution would yield good results: keep beam slope before and after break identical (except for some beam quanting, perhaps, but that's less than 0.3 ss), but modify stem lengths: make them as long as they would be if there were no beam on the other side of the break. I would expect this to yield mostly reasonably results. I'd also keep beam orientation. But it might make sense to dole out a bit of spring force (just decidedly less than infinite) for making the vertical beam positions at the break match. It would seem that this algorithm would fail for a simple broken beam a8[ b \break c f] Care to elaborate? The a to b beam would have a slope of 1 ss per eighth note. The c to f beam would have a slope of 3 ss per eighth note. the a to f beam would have a slope of 5 ss per 4 eighth notes, or 1.2 ss per eighth note. per 3 eighth, or 1.67 ss per eighth. If you choose the slope of 1.2 for both sides, 1.67 ss then it seems to me that the b stem will be longer than it would be without the beam on the other side of the break, Yes. and the c stem would be longer than it would be without the beam on the other side of the break. Yes. If you force the b and c stems to be the same length, the a and f beams would be too short. Why would one force them to be the same length? If we have an equalizing infinite force applying, it would force the b stem to be 1.67ss shorter than the c stem. Of course, the usual beam scoring would apply in order to make sure that no stem gets too short. I don't get your point. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Broken beams' slopes
Hey all, I'll be leaving on vacation in a week-ish, and as my summer-of-lily comes to a close, I can likely do one more medium-scale thing before I have to start correcting parallel fifths. I'd like to work on broken beam slopes such that a beam can break across lines and pick up where it left off at the same slope and y-offset The approach would be: 1) Get rid of the chained callbacks to calculate Beam #'position. 2) Work on the Beam_scoring_problem class such that it does everything that all of the chained callbacks used to do. 3) Make the calculations in Beam_scoring_problem such that they always unfold in a coordinate space where the origin is at the X and Y offset of the first normal stem (the latter of which should, aside from really esoteric cases, always be 0.0). This way, it is relatively trivial to tack on information from extra systems (or not) - grobs on subsequent systems have their x-displacement added onto the combined spanner lengths of previous systems plus the tiny part of the broken beam between its left bound and the first stem on a new system. I estimate that this will take me two days of work, so please respond in the next 48ish hours if you think this is a bad idea. Otherwise, I'm gonna give it a go. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
Mike Solomon mike...@ufl.edu writes: Hey all, I'll be leaving on vacation in a week-ish, and as my summer-of-lily comes to a close, I can likely do one more medium-scale thing before I have to start correcting parallel fifths. I'd like to work on broken beam slopes such that a beam can break across lines and pick up where it left off at the same slope and y-offset The problem I see with this approach is that one does not, in general, want the same slope and y-offset because it does not make sense to view the broken beam as a single visual entity. Creating a single visual entity often means compromises like having over-long or -short stems in between. When in between moves right adjacent to the break, you don't want the stems there to be overlong and overshort just to make y positions match those of the next line. The next line is far away. So you will generally want to preserve the beam slope roughly, and preferably the beam orientation. That means that if the unbroken beam would have a _knee_ at the break, you would, when splitting it, tend to prefer _unkneed_ beams with similar slope, even though that would mean a significant jump in y-offset. But that makes the visual connection easier to make than a jump in beaming direction. So thea esthetic decisions need to work under different constraints than in the unbroken case. We have the same almost, but not quite as if unbroken situation with slurs and ties. And it does not just occur with line breaks, but also in connection with repeats and da capo. Do we have a sound general strategy for tackling this sort of controlled discontinuity? Maybe it would be worth thinking about. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
On Aug 24, 2011, at 5:42 PM, David Kastrup wrote: Mike Solomon mike...@ufl.edu writes: Hey all, I'll be leaving on vacation in a week-ish, and as my summer-of-lily comes to a close, I can likely do one more medium-scale thing before I have to start correcting parallel fifths. I'd like to work on broken beam slopes such that a beam can break across lines and pick up where it left off at the same slope and y-offset The problem I see with this approach is that one does not, in general, want the same slope and y-offset because it does not make sense to view the broken beam as a single visual entity. All the pdfs associated with my response are up at http://www.apollinemike.com/response_to_david See chords2.pdf versus chords.pdf. In chords.pdf, I use an override to make all beams flat. In chords2.pdf, I remove this override and let lily run her course. I think that, in chords2.pdf, the disparity in slopes across line breaks makes for really ugly typsetting. I would much rather have long stems and continuity than more even stems and divergent slopes. Creating a single visual entity often means compromises like having over-long or -short stems in between. When in between moves right adjacent to the break, you don't want the stems there to be overlong and overshort just to make y positions match those of the next line. The next line is far away. In the case of beams, I actually think people often want this. Check out measure 6 of broken.pdf. I would gladly take a long stem before the line break (the same length, for example, as that of the D natural in the previous beam) such that the slope and Y-offset are continuous. I think that it is important to make a scorer that can work on a per-line or all-line basis (like the one I'm proposing) so that people can decide between the two with a property (Beam #'preserve-slop-across-line-breaks). So you will generally want to preserve the beam slope roughly, and preferably the beam orientation. I think that in the included PDFs, even roughly wouldn't work (I haven't tried though) - as a performer, especially at fast tempos, the consistency of slope would actually help me anticipate what is coming after the line break so that my hands can move in the right direction. That means that if the unbroken beam would have a _knee_ at the break, you would, when splitting it, tend to prefer _unkneed_ beams with similar slope, even though that would mean a significant jump in y-offset. Agreed. But that makes the visual connection easier to make than a jump in beaming direction. Agreed. So thea esthetic decisions need to work under different constraints than in the unbroken case. Agreed. We have the same almost, but not quite as if unbroken situation with slurs and ties. And it does not just occur with line breaks, but also in connection with repeats and da capo. True, but I think these grobs are different because they hover over or under early columns like clefs and key signatures, whereas beams start after these columns. This allows beam continuity to be a lot better, as it does not have to compete with the presence of a giant clef at the beginning of the barline that would cause its y-offset to be very high or low. Do we have a sound general strategy for tackling this sort of controlled discontinuity? Maybe it would be worth thinking about. Not really, although I'm way for this (my vector graphics spanner does this sorta thing). I think implementing this type of continuity for beams may be a good test case from which a general strategy (if appropriate) can be extrapolated and applied elsewhere. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken beams' slopes
Mike Solomon mike...@ufl.edu writes: On Aug 24, 2011, at 5:42 PM, David Kastrup wrote: Mike Solomon mike...@ufl.edu writes: I'll be leaving on vacation in a week-ish, and as my summer-of-lily comes to a close, I can likely do one more medium-scale thing before I have to start correcting parallel fifths. I'd like to work on broken beam slopes such that a beam can break across lines and pick up where it left off at the same slope and y-offset The problem I see with this approach is that one does not, in general, want the same slope and y-offset because it does not make sense to view the broken beam as a single visual entity. See the attached chords2.pdf versus chords.pdf. In chords.pdf, I use an override to make all beams flat. In chords2.pdf, I remove this override and let lily run her course. I think that, in chords2.pdf, the disparity in slopes across line breaks makes for really ugly typsetting. Agreed. I would much rather have long stems and continuity than more even stems and divergent slopes. But the continuity demands are less stringent across the break. You can fuzz with beam slope somewhat (things should likely stay rising, straight, or falling, but the degree is likely more flexible than without a break), and you can fuzz quite a bit with y position when needed before you get negative returns. Of course, without a good reason there is no point to change either. Being able to keep them identical is a good start. I am just pointing out that it is not the optimum, and one should likely not try to lose sight of the optimum entirely, even if it may not make it into code right away. That means that if the unbroken beam would have a _knee_ at the break, you would, when splitting it, tend to prefer _unkneed_ beams with similar slope, even though that would mean a significant jump in y-offset. Agreed. But that makes the visual connection easier to make than a jump in beaming direction. Agreed. So the aesthetic decisions need to work under different constraints than in the unbroken case. Agreed. We have the same almost, but not quite as if unbroken situation with slurs and ties. And it does not just occur with line breaks, but also in connection with repeats and da capo. True, but I think these grobs are different because they hover over or under early columns like clefs and key signatures, whereas beams start after these columns. This allows beam continuity to be a lot better, as it does not have to compete with the presence of a giant clef at the beginning of the barline that would cause its y-offset to be very high or low. Agreed. I guess we are in violent agreement. Just wanted to be sure that this point was not accidentally overlooked completely, possibly making things harder to do better at a later point of time. Do we have a sound general strategy for tackling this sort of controlled discontinuity? Maybe it would be worth thinking about. Not really, although I'm way for this (my vector graphics spanner does this sorta thing). I think implementing this type of continuity for beams may be a good test case from which a general strategy (if appropriate) can be extrapolated and applied elsewhere. Thanks for keeping an alert mind. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
