lilypond-devel
[Top][All Lists]
Advanced

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

Re: LilyPond speed. Idea for Schikkers list


From: Janek Warchoł
Subject: Re: LilyPond speed. Idea for Schikkers list
Date: Thu, 10 Mar 2011 00:42:11 +0100

2011/3/9 Han-Wen Nienhuys <address@hidden>
>
> 2011/3/6 Janek Warchoł <address@hidden>:
> > Hi,
> >
> > how fast would be LilyPond if we turned off collision detecting,
> > optical spacing, line breaking, beam quanting and sloping, slur
> > shaping, etc etc etc - basically everything except placing symbols on
> > paper in one infinately long system?
>
> You can easily try this out yourself. Just set ragged-right=##t and
> set linelength to 100 meters (or something).  You may need to remove
> some internal sanity checks on distances.

No, that's not what i meant. I want to ignore almost all aspects of
engraving (for example calculating beam slopeness), not only line
breaking. At first i thought that removing engravers would do the
trick, but for example if i remove beam_engraver entirely, i won't get
any beams at all.
Maybe i should've explained why i ask this question. My idea for
shikkers list is this: it would show a user only a rough preview of
music, with everything in one infinite system (like scroll view in
finale), and laid-out in a not-so-pretty way (for example with
slur-accidental collisions and beams that are all flat). It would
still be necessary to compile the score in order to see final result,
but this rough preview would be easier to work with than pure text
mode, at least for users used to GUI.
The usability of this idea depends on the answer to this question: how
much can we speed up compiling by skipping some calculations that are
not totally crucial to displaying the music? If it's bigger than 90%,
it may be worth a try.

thanks,
Janek

PS Actually when i tried what you suggested compiling was twice longer
than normally.



reply via email to

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