On 7 sept. 2012, at 09:34, k-ohara5...@oco.net wrote: > On 2012/09/04 08:09:21, mike7 wrote: > >> On 4 sept. 2012, at 09:45, mailto:k-ohara5...@oco.net wrote: > >> > It makes no change for the Chopin; can you give an >> > example where it helps? > >> In the Chopin, ragged-bottom is false so the difference can't >> really be seen. The piece isn't a good test case for how the >> patch changes engraving but it is an excellent test case for >> efficiency. > > Did you need me to type \paper{ ragged-bottom=##5 } for you? > <http://k-ohara.oco.net/Lilypond/> > With ragged-bottoms, master allows about 8 collisions between slurs and > the pedaling in the system above, of which the patch removes 4. That's > not good enough to be worth the extra %15 time for me, but I guess I can > just turn it off.
In terms of sustainability, the most important question to ask at this point is "does this method seem like one that could eventually suppress 8/8 collisions?" I think it can, but I probably won't have the time to get it there as my summer of lily comes to a close in 2 weeks and I'll disappear back into a hole save bug fixes and occasional complaining. So if we're gonna go w/ this, it's important to agree that grob "stubs" are a good solution to this problem. I am, of course, open to other solutions. The nice thing about this one is that it's easy to turn off. Or, even better, it's easy to turn on and we can leave it off as default. The same goes for my recent skyline work - I'm all for having different includable files in ly/ like "fast.ly" % turns off tons of calculations to create an ugly score fast "medium.ly" % does most calculations but avoids fine-tuned collision avoidance "slow.ly" % the full monty > >> SlurStubs run the control point calculations using not the >> actual heights and coordinates (which would trigger a vertical >> alignment) but rather pure heights and coordinates. > > So SlurStubs have a different shape than slurs. That would be an > example of the different information that I was asking about. > Ja. > Having the invisible Grobs taking up space will confuse the innocent. I tried to add comments about this in the source - perhaps the CG needs an invisible grob bit, as we have StemStubs and SpanBarStubs as well. > > In measure 36 of my example, it seems I used a text script for custom > fingering placement. That "4" moves to avoid the SlurStub. (How would > you put it back where it belongs, as a user? ) \override TextScript #'avoid-slur = #'inside \override TextScript #'outside-staff-priority = ##f you may also have to set the Y-offset to something in side-position-interface.cc - I forget what the default Y-offset is. > > Do you still think it possible to use just the real Slurs ?... > No. But, as I said above, I'm open to other suggestions. > 1) setting tentative control points using pre-line-breaking estimates of > heights (which are later replaced when the Slurs go through their > post-line-breaking shaping-and-scoring cycle). This doesn't work because all of this skyline stuff happens pre-line breaking but post-vertical spacing. And furthermore, there needs to be a SlurStub for each axis group traversed. > > 2) Determining their extremal-side-only skylines, either through > callbacks on a property other than the real "vertical-skylines" , or not > as a callback at all but through a direct function call. Even if this were done, it couldn't be applied to the Slur proper. For example, if you have slur S that cross staves X Y and Z from bottom to top, the SlurStub on X would only have a bottom skyline, the SlurStub on Y would have no skyline and the slur stub on Z would have an upper skyline. If the Slur had these two skylines via some sort of pre-skyline callback, LilyPond would think that the VerticalAxisGroup were the height of the Slur and would space it way far apart from its upper or lower neighbor. That's why separate stubs need to be in each axis group. > >> http://codereview.appspot.com/6498077/ > > > http://codereview.appspot.com/6498077/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
