Re: Retrieving information about breaks (was: Partial compilation (again))
Hi Urs,
On Fri, Jan 23, 2015 at 9:33 AM, Urs Liska wrote:
> Picking up that old thread seems better than starting a new one ...
>
> By now I've reached a different state and would like to come back to this
> issue with a very concrete question:
> Is it possible to determine at which positions (in terms of barnumber and
> measure-position) the final line breaks, page breaks and page turns have
> been placed in LilyPond?
> I'm sure this information has to be present at one point, but someone (I
> think it may have been David Nalesnik) expressed the opinion that engravers
> could only access explicit \break-s.
>
> I would like to write out a log file containing all break points of a
> given LilyPond run.
>
Here's a routine which will write the line breaks to a file. Have to look
into page breaks/turns. (It may be that you need explicit page
breaks/turns--then it's possible to read 'page-break-permission and
'page-turn-permission.)
\version "2.19.15"
%% breaks
#(define out (open-output-file "line-breaks.txt"))
#(define (display-breaks grob)
(if (and (grob::has-interface grob 'paper-column-interface)
(eq? #t (ly:grob-property grob 'non-musical)))
(if (eq? 1 (ly:item-break-dir grob))
(let* ((location (ly:grob-property grob 'rhythmic-location))
(m (car location)))
(format out "Line beginning at measure ~a~%" m)))
(ly:message "Need NonMusicalPaperColumn grob to determine line
breaks.")))
\relative c'' {
\override Score.NonMusicalPaperColumn.after-line-breaking =
#display-breaks
\repeat unfold 30 { c d e f }
}
Hope this helps--
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Retrieving information about breaks (was: Partial compilation (again))
Picking up that old thread seems better than starting a new one ... By now I've reached a different state and would like to come back to this issue with a very concrete question: Is it possible to determine at which positions (in terms of barnumber and measure-position) the final line breaks, page breaks and page turns have been placed in LilyPond? I'm sure this information has to be present at one point, but someone (I think it may have been David Nalesnik) expressed the opinion that engravers could only access explicit \break-s. I would like to write out a log file containing all break points of a given LilyPond run. If that's not currently accessible I'd like to add that as a feature request. Urs Am 21.11.2014 um 14:44 schrieb Urs Liska: Am 21.11.2014 13:33, schrieb David Kastrup: Urs Liska writes: Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup : So I don't see this going anywhere fast. To get a hook into cloning internal engraver states, you'd probably want to create a more object-oriented frame work for them. Ok, I see. Thank you for the explanation. I'll try if I can get *somewhere* with an "external" approach as outlined on -user. TeX, in contrast to LilyPond, works in a pipeline-like manner, producing output all the time. In that case, a semi-external approach might work when you have a good idea what kind of input is subject to editing: you just fork off a copy of the executable when it gets to the place before the editing region. And then you run that forked copy on the changed input from that point on. However, LilyPond first consumes all input and then starts processing, so the input file pointer into an unchanged part of the input is just not a useful indicator of LilyPond's progress and this kind of low-level approach does not look workable. OK. I will try around anyway. If I knew where a given system starts in terms of barnumbers I can try: - setting suitable skipTypesettings commands one measure before and one measure after the range - check for open spanners and optionally inject corresponding starts/ends in the respective "preroll" measure - add manual breaks before and after the line - compile this threeline document to three temporary files (with lilypond-book-preamble) - replace the respective previous system's pdf with the new one. setting system-count to 3 will result in the right document in any case, and in warnings when the system gets too full (so the recompilation doesn't work anymore). Of course this isn't intended for the part of bringing a score to publication quality but rather for the stage when you're only dealing with the content. And I don't know how complicated things will become. But I think it is worth a try. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partial compilation (again)
Am 21.11.2014 13:33, schrieb David Kastrup: Urs Liska writes: Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup : So I don't see this going anywhere fast. To get a hook into cloning internal engraver states, you'd probably want to create a more object-oriented frame work for them. Ok, I see. Thank you for the explanation. I'll try if I can get *somewhere* with an "external" approach as outlined on -user. TeX, in contrast to LilyPond, works in a pipeline-like manner, producing output all the time. In that case, a semi-external approach might work when you have a good idea what kind of input is subject to editing: you just fork off a copy of the executable when it gets to the place before the editing region. And then you run that forked copy on the changed input from that point on. However, LilyPond first consumes all input and then starts processing, so the input file pointer into an unchanged part of the input is just not a useful indicator of LilyPond's progress and this kind of low-level approach does not look workable. OK. I will try around anyway. If I knew where a given system starts in terms of barnumbers I can try: - setting suitable skipTypesettings commands one measure before and one measure after the range - check for open spanners and optionally inject corresponding starts/ends in the respective "preroll" measure - add manual breaks before and after the line - compile this threeline document to three temporary files (with lilypond-book-preamble) - replace the respective previous system's pdf with the new one. setting system-count to 3 will result in the right document in any case, and in warnings when the system gets too full (so the recompilation doesn't work anymore). Of course this isn't intended for the part of bringing a score to publication quality but rather for the stage when you're only dealing with the content. And I don't know how complicated things will become. But I think it is worth a try. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partial compilation (again)
Urs Liska writes: > Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup : > >>So I don't see this going anywhere fast. To get a hook into cloning >>internal engraver states, you'd probably want to create a more >>object-oriented frame work for them. > > Ok, I see. Thank you for the explanation. > > I'll try if I can get *somewhere* with an "external" approach as > outlined on -user. TeX, in contrast to LilyPond, works in a pipeline-like manner, producing output all the time. In that case, a semi-external approach might work when you have a good idea what kind of input is subject to editing: you just fork off a copy of the executable when it gets to the place before the editing region. And then you run that forked copy on the changed input from that point on. However, LilyPond first consumes all input and then starts processing, so the input file pointer into an unchanged part of the input is just not a useful indicator of LilyPond's progress and this kind of low-level approach does not look workable. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partial compilation (again)
Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup : >Urs Liska writes: > >> I have another suggestion, somewhat related to >> >http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html >> >> I would still like to see the possibility to re-compile individual >> staves only. >> And with a sloppy-line-breaking option (maybe in combination with >> system-wise output à la lilypond-book-preamble) risk is much lower >> that changes in line breaking interfere with that. (Of course that >> scenario has to be taken into account). > >[...] > >> I know this may be a rather big task, but I think that adding a >> partial compilation feature would be a very good thing in order to >> keep (or even make) LilyPond more competitive. > >For one thing, it's a lot of a hen-and-egg problem. This would require >heavy support from the application driving LilyPond. I see this as >somewhat more feasible from systems like Denemo rather than Frescobaldi >since Denemo understands the LilyPond code it produces and would be >able >to figure out the details involved with retypesetting parts. > >For stuff like Frescobaldi, I don't really see reliable strategies. >For >MusicXML rather than the LilyPond input language, stuff might be more >straightforward. Of course, parsing is a pretty fast part of LilyPond >so one could likely afford not doing partial reparsing but reparse the >whole document and consequently work on a less stateful representation >of the score. Doing partial iteration would be trickier since the >state >is not just stored in context properties but also in engravers' own >local variables. > >In either case, the problem space is similar to that of the much wider >used LaTeX, and for LaTeX there are no really convincing retypesetting >scenarios (well, preview-latex works in a problem subspace that's handy >for editing but not-the-real problem, and I don't see that easily >extending to LilyPond which works with a much larger amount of relevant >hidden state being dragged around during compilation). > >So I don't see this going anywhere fast. To get a hook into cloning >internal engraver states, you'd probably want to create a more >object-oriented frame work for them. Ok, I see. Thank you for the explanation. I'll try if I can get *somewhere* with an "external" approach as outlined on -user. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partial compilation (again)
Urs Liska writes: > I have another suggestion, somewhat related to > http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html > > I would still like to see the possibility to re-compile individual > staves only. > And with a sloppy-line-breaking option (maybe in combination with > system-wise output à la lilypond-book-preamble) risk is much lower > that changes in line breaking interfere with that. (Of course that > scenario has to be taken into account). [...] > I know this may be a rather big task, but I think that adding a > partial compilation feature would be a very good thing in order to > keep (or even make) LilyPond more competitive. For one thing, it's a lot of a hen-and-egg problem. This would require heavy support from the application driving LilyPond. I see this as somewhat more feasible from systems like Denemo rather than Frescobaldi since Denemo understands the LilyPond code it produces and would be able to figure out the details involved with retypesetting parts. For stuff like Frescobaldi, I don't really see reliable strategies. For MusicXML rather than the LilyPond input language, stuff might be more straightforward. Of course, parsing is a pretty fast part of LilyPond so one could likely afford not doing partial reparsing but reparse the whole document and consequently work on a less stateful representation of the score. Doing partial iteration would be trickier since the state is not just stored in context properties but also in engravers' own local variables. In either case, the problem space is similar to that of the much wider used LaTeX, and for LaTeX there are no really convincing retypesetting scenarios (well, preview-latex works in a problem subspace that's handy for editing but not-the-real problem, and I don't see that easily extending to LilyPond which works with a much larger amount of relevant hidden state being dragged around during compilation). So I don't see this going anywhere fast. To get a hook into cloning internal engraver states, you'd probably want to create a more object-oriented frame work for them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Partial compilation (again)
I have another suggestion, somewhat related to http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html I would still like to see the possibility to re-compile individual staves only. And with a sloppy-line-breaking option (maybe in combination with system-wise output à la lilypond-book-preamble) risk is much lower that changes in line breaking interfere with that. (Of course that scenario has to be taken into account). The benefit of such an option would be a much more responsive user experience, and this could be made fruitful in editors or, e.g., web applications: when something changes that doesn't affect line or page breaking LilyPond only has to recompile the relevant section (I'd say system). This is an approach that is taken by Amadeus (which recompiles the current page), and will also be taken by the new Steinberg application. I don't know concretely what it will be like, but in one of the blog posts Daniel Spreadbury elaborated on determining the necessary minimum range for recompilation to find the best possible trade-off between realtime experience and engraving quality. I think it would behave very similarly to the skipTypesetting approach, with a few differences: - the recompiled range doesn't appear to be the beginning of the score (no indent, no instrumentName (but shortInstrumentName) - barnumbers and mark numbers (and maybe other items) should also reflect the real values As they are broken items anyway there should be no impact on their formatting anyway Maybe it would be good to restrict this to system-wise output because I don't have a clue how it should be possible to replace a system from within an existing PDF document. Maybe it's different with SVG output, though. If sloppy line breaking is active determining the need of recompiling the whole document would only mean checking if the modified range still fits on a line. I see two ways to approach the counter issue mentioned above: The whole score could be parsed again, so the reduction of work load only affects the layout process (which is probably much more expensive anyway). A LilyPond run will produce an external helper file providing meta information about the systems. I can imagine such information to be useful in other circumstances too. I'd even say with such information it could be possible to create such a partial compilation scheme at user-level. I know this may be a rather big task, but I think that adding a partial compilation feature would be a very good thing in order to keep (or even make) LilyPond more competitive. Best Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
