Re: Sibelius Software UK office shuts down

[Graham Percival]

On Thu, Aug 02, 2012 at 06:22:49PM +0200, address@hidden wrote:
> On 2 août 2012, at 18:18, Lucas Gonze wrote:
> 
> > Is it architecturally possible to make a significant amount of
> > overhead go away? Are incremental compiles plausible?
> 
> It is very difficult.  It's better to use a front-end editor
> that shows some sorta mock-up of the score and that only
> compiles the nice LilyPond version from time to time (if this
> exists).  Getting an actual LilyPond score requires calculating
> line breaks and there's no way to get rid of the overhead.

Sure there is.  Compile each bar individually with the default
spacing (i.e. whatever you get if your entire score is one bar and
you use ragged-right=##t).  The concatenate bars until the sum is
larger than the allowable line-width, at which point you put the
bar on the next line.

It'll be completely ugly (ragged score lines?  even finale doesn't
do that!), but it eliminates the overhead of line breaks.  Then
the question is what trade-offs of speed for beauty you want to
make.  I mean, a slightly less invasive/drastic speed-up would be
to have the user hard-code 4 bars per line.  That's also ugly, but
not as bad as the previous option.


In short: if there is a concerted effort to create a "quick
render" output, I would be absolutely shocked if it wasn't at
least 10 times faster than the current output.  Kill line breaks,
draw slurs as rectangles, place noteheads on a strict timing grid
instead of optical spacing... there's a lot of beautiful things
that lilypond does which uses CPU resources.

> As for the svg, significant improvement can be made in the speed
> of LilyPond's svg export - contributions are certainly welcome
> in this area.  The backend is very well written but it is all in
> Scheme

The "compiled scheme" in guile 2.0 could help here.  So if anybody
feels like picking up the porting-to-guile2.0 work...

- Graham