On 14 mai 2012, at 11:22, Joseph Rushton Wakeling wrote: > On 14/05/12 09:56, David Kastrup wrote: >> <URL:http://lilypond.org/doc/v2.15/Documentation/source/Documentation/notation/skipping-corrected-music> > > Yes, but that wasn't the use-case I had in mind. The sort of thing I was > thinking of was: > > (i) I have a full, complete score, which I have compiled. > > (ii) I spot a typo (say, an A that should be A-flat). > > (iii) I correct the wrong note and recompile. The recompilation process > ought to be significantly faster than the original complete-score > compilation process, even though a full score is being produced as > output.
This is very hard because of the butterfly effect - an A-flat in an already-crammed line could lead to new line breaking, which means new vertical spacing etc.. I only see two ways of handling this: 1) An aux file that is able to act as a sort of diff to the current file so that the creation of Grobs is accelerated during the interpretation process (a speed up of about 15% on orchestral scores, 1-ish% if that on simple scores). 2) LilyPond running in server mode on your machine where it takes an input file and runs a lot of "contingencies" as a background process. That is, it starts with the most recent successfully compiled score and rules-out different line breaking configurations. For example, it'd add accidentals to groups of notes to test what that did to line-breaking and come up with categories of cases where the line breaking didn't change. If a new run of LilyPond on a corrected score falls into one of these categories of cases, then LilyPond uses a stashed result for line breaking. Machines 20 years ago would have died doing this, but I actually think its possible now. One of the reasons that Instagram is so cool is because it does a similar thing: it starts uploading a photo while you're writing captions and browsing through filters and applies certain filters to the uploaded file and to the local file once the decision is made. As a result, the upload seems instantaneous. But for us, this would easily take a Google summer of code...and fall of code...and winter of code...and... Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel