Hi, sorry for delayed reply - i had a busy weekend (been on a wedding!)
2014-07-05 19:46 GMT+02:00 Keith OHara <k-ohara5...@oco.net>: > On Fri, 04 Jul 2014 14:38:19 -0700, Janek Warchoł <janek.lilyp...@gmail.com> > wrote: > >> 2014-07-04 23:26 GMT+02:00 Janek Warchoł <janek.lilyp...@gmail.com>: >>> >>> >>> That's actually not what i want to do; I apologize for being unclear. >>> I *want* the columns to behave the same way in case of both >>> accidentals and lyrics (and everything else). The desired behaviour >>> is that changing min_distance shouldn't affect ideal distance. > > > Sensible, for the data object Springs. The special behavior when > min_distance is larger or within 0.3 of ideal is confusing. The fact that > the special behavior appears only after using merge_springs() makes things > more confusing. Definitely. > Notice that frax/springs keeps that special behavior, in Spring::length(). > The natural, force=0, length of a spring is *always* at least > min_distance+0.3 Yes, and that's intended (see below). However, there may be a better way of implementing this - i'm not fully satisfied with how it's done in frax/springs. >>> Achieving this [desired, not-special] behaviour when columns arewide due >>> to lyrics is simple: > >> but there >> are side effects (too tight spacing in some cases, for example in >> beam-rest-extreme.ly) which i'm unable to fix. > > > Trace back and see what code uses that +0.3 to good effect, though probably > by accident. > > Only spacing-spanner.cc uses Spring::merge_springs(), and when setting > 'beam-rest-extreme.ly' it is used to 'merge' only one spring! Interesting, i didn't notice that! > So one good effect is that accidentals are prevented from getting too close > to the previous note. That would be better handled with padding associated > with the accidental > <http://code.google.com/p/lilypond/issues/detail?id=3869> I'm not sure if this actually is what we want. Padding would mean that the accidental _never_ gets close to the previous notehead, while we would acutally want to permit that when the compressing force is sufficiently large. So, i think that this has to be done at the level of springs. > You could limit the changes in one patch, if you like, by moving the "ideal > = max(idea, min_distance +0.3)" to the point where spacing-spanner.cc finds > min_distance to avoid collisions. A magic number is better than a magic > number in a mysterious place, and making the 0.3 a parameter is safer to do > after we narrow down its beneficial effect. > > If merge_springs() behaves more simply, it might do a little better for > <http://code.google.com/p/lilypond/issues/detail?id=3887> > (I notice that the option 'average-spacing-wishes' is no longer checked; the > code seems to always average spacing between voices.) ok - this looks like a good path to follow. Unfortunately, i don't know when i'll have enough time to chew on this stuff - it seems that i'll have a busy week (or two). Please don't feel ignored if I post a new alignment-related patch instead of working on this issue - i still understand alignment code much better than springs, so i can put togethter an alignment patch in time that would be insufficient to do anything reasonable with springs. Anyway, thanks a lot for your comments - i understand the springs better now. Sooner or later a patch will be written :) best, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
