Am 14. April 2017 16:04:31 MESZ schrieb David Nalesnik <david.nales...@gmail.com>: >On Fri, Apr 14, 2017 at 1:38 AM, Urs Liska <u...@openlilylib.org> wrote: >> >> >> Am 13.04.2017 um 16:48 schrieb David Nalesnik: >>> On Tue, Apr 11, 2017 at 5:54 PM, Urs Liska <u...@openlilylib.org> >wrote: >>>> >>>> Am 11.04.2017 um 21:04 schrieb tisimst: >>>> >>>> >>>> >>>> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden >email]> >>>> wrote: >>>>> >>>>> >>>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn: >>>>>> Am 11.04.2017 um 20:36 schrieb Urs Liska: >>>>>>> So, is there any moment in the compilation process where the >natural, >>>>>>> unstretched length of a measure can be calculated? It doesn't >have to >>>>>>> be >>>>>>> an easily-read property and can involve calculation, but >actually the x >>>>>>> position of the barlines would be an easy target - *if* there's >this >>>>>>> magic moment in the compilation pipeline ;-) >>>>>> Maybe you could experiment with the ly:one-line-breaking? >>>>> I don't think so (only, of course, to investigate how much can be >done >>>>> on the internal level). >>>>> Basically what I'm after is a ly:cheap-line-breaking mode that >doesn't >>>>> care at all about overall appearance or good page turns but >instead >>>>> simply places as many measures in a line as fit naturally. If then >a >>>>> line break changes and I know the natural width of the measures I >can >>>>> determine before compilation how many measures will fit on the >*next* >>>>> system. >>> But given clefs, key signatures, cautionaries, doesn't this mean >that >>> you need to know the width of any measure as the first measure of >the >>> line, as the last measure on a line, at a median position? >> >> Ah yes, this is true. But I guess we could do with some estimates >here >> (see below). >> >>> >>> I'm not clear on the need to know how many measures will fit on >>> subsequent lines before compilation. Is it so that you can compile >by >>> system? >>> >>> (Just trying to get a handle on your goals so I can help better.) >> >> Yes, you're right. I'm not going to tackle this right now, but I have >to >> think about it for writing some plans. >> I'm thinking about a "music entry mode" where I don't care at all >about >> "good" line and page breaking, so music can just be engraved like >Word >> "justifies" paragraphs - just fill the line and then go to the next. > >Doesn't ly:minimal-breaking already do this? It might try out >different line configurations -- I'm not entirely sure -- but looks >pretty stripped down.
I'll have a look into that, but it's of course only half of the equation. > >> >> Given that the music is available in a measure-by-measure state and >> given that it is available in a parsed state from a LilyPond server >> (both of which I hope to achieve one day) this would mean that I can >> simply recompile the "current" system as long as the changed don't >> require a change in line breaking. Only then I'd have to recompile >the >> next system as well, and then the next if the changed lines requires >> this. I could do this sequentially, so the score would also update >> incrementally without having to wait for the full compilation. But if >I >> knew the natural width of each existing measure I could perform the >> calculations up front and decide which system should contain which >> measures. In that case one could even have the systems be engraved in >> parallel. >> If any of these subsequent system fails because the measures don't >fit >> on it (BTW some help could be available by LilyPond's ability to >squeeze >> the system a bit) the parallel engraving could be stopped and >restarted >> in the incremental fashion. > >OK, I understand. This would be a great selling point.. > >Possibly related: have you considered the page/scroll view option from >*ahem* Finale? (In scroll view, of course, all music is on a single >line, whereas page view presents pages roughly as they will be >engraved.) That was the first I used as notation interface, back with Finale 2001. That would be an option as well, with just one system in the window. For a main interface I think thus provides too little context to know where you are. But what I *did* think about is a kind of instant preview widget jusg showing, say, the current "cursor" +/- one measure. > >About "natural measure widths": I'm still poking around, hoping that >you wouldn't need to run a copy of various structures through the >page/line breaking algorithms. > >> >> Urs >> >> PS: Still, I haven't found the opportunity to install the latest >version >> to test your suggestions. >> > >Oh, I just added the latest bell-and-whistle assuming that you're >always at the forefront! As I'm currently starving on an OS without Guile 1 I can't run self-compiled Lilys. And with the binary releases I've never been that quick to update. Urs > You can get the extents in other ways: > >Replace > > (lambda (c) (ly:paper-column::break-align-width c '(break-alignment))) > >with > >(lambda (c) (ly:generic-bound-extent c sys)) > >or > >(lambda (c) (ly:grob-extent c sys X)) > >HTH, >David _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user