Re: Keep parsed document in memory

[Urs Liska]

Hi Sharon,

Am 22.02.2016 um 20:22 schrieb Sharon Rosner:
>> I worked on a large score with about 100 A3 pages with 13 point staff
>> size (~ 50 minutes of huge orchestra).
>>
>> Compiling the full score using manual breaks took around 7 minutes, with
>> the console output seemingly indicating the switch from parsing to
>> engraving after around 1'30.
>> Then I set up a system to compile a single system using skipTypesetting,
>> which took a little more than 1'30.
>>
>> So I think when I could recompile a score that is kept in memory I could
>> (more or less) skip these first 1'30.
> I'd say this also depends on how you structure your source file(s). 

Well, maybe I didn't make myself clear enough, but I'm not looking for a
solution for best practice or a concrete project I'm working on but
rather a generic improvement for LilyPond.

> If the
> music is in one continuous movement and you don't split it into multiple
> sections (e.g. a separate variable for every 20 bars), you'll run into the
> kind of situation you describe. 

I don't really see why that should be. Of course our score was
excessively split into variables (see
http://lilypondblog.org/2014/10/segment-grid/), but when working on the
full score that doesn't really matter, I think.

> Have you tried working on each part
> separately? If your'e talking about doing tweaks and editorial annotation,
> then surely you can work in this manner?

Of course. In the case of that project I even had a function to compile
just one short segment of one part, which proves very useful for working
on the content.

But as said I'm researching a generic solution that doesn't rely on a
certain set-up of a score.

>
>> I already have a tool in place (in openLilyLib) where you can pass a
>> list of barnumbers (a.k.a the original breaks from the source) and then
>> ask LilyPond to compile e.g. systems 4-7, page 3 or similar.
> Another approach would be to use a preprocessor that automatically cuts your
> source files up, then feeds them into Lilypond. This is the approach I'm
> currently exploring with my lydown tool, but this is something beyond the
> scope of the current discussion.

We're actually discussing this too. But for the process of tweaking the
layout (i.e. don't modify the content anymore) it would be even more
efficient to *not* redo any parsing.

Actually, GridLY is also providing such functionality. It stores the
music in a grid, and it can output any range of columns from that grid.
This is already pretty efficient when it comes to recompiling a score,
but it really imposes a strong structure on your input files, so I don't
think that is anywhere near being sufficiently generic.

>
>> As said above I'm convinced that even when it *is* the smallest part
>> (which I don't question) a set-up as I see it (well, it will have a
>> number of steps to achieve until it'll show it's real face) can make a
>> huge difference from the user's perspective.
> Having worked on numerous big scores I've found that if you separate the
> instrumental parts into separate files you can work quite efficiently on
> fixes, tweaks and annotations. I've developed two different tools that act
> as pre-processors to aid in the process of putting together big scores and
> extract instrumental parts, but that's another story.

Well, as said, I'm not looking for the solution to an actual project's
problems. I'm talking about investing serious time and effort in
LilyPond development for a solution that can then be supported by
editing environments. The eventual outcome should be an interface for
graphical editing of scores with near-instant feedback.

Best
Urs

>
> Sharon
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/LilyPond-as-a-service-tp187403p187557.html
> Sent from the Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel