Re: Keep parsed document in memory

[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). 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. 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?

> 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.

> 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.

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.