[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Partial compilation (again)

From: Urs Liska
Subject: Partial compilation (again)
Date: Fri, 21 Nov 2014 12:08:05 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

I have another suggestion, somewhat related to

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]