[Joe Neeman]
With the optimisations, it scales like (left column is the number of scores)
24 2m0.017s
19 1m23.650s
14 0m52.611s
9 0m27.961s
4 0m11.139s
1 0m4.402s
as you can see, it isn't O(n) but it isn't much worse either. The further
optimisations I have planned should make it even closer to
On Thursday 03 May 2007 00:53, Han-Wen Nienhuys wrote:
> 2007/5/2, Joe Neeman <[EMAIL PROTECTED]>:
> > > Well, I have seen that the Lilypond version 2.8.8 can easily be
> > > installed in the local directory, and with that, everything compiles in
> > > a couple of seconds with no fuss.
> >
> >
On Wednesday 02 May 2007 23:03, Arvid Grøtting wrote:
> 2007/5/2, Joe Neeman <[EMAIL PROTECTED]>:
> > With my working copy of lilypond (on a 1.6 GHz Opteron), I have this down
> > to 3m22.321s. That's still about 3 times slower than 2.8 but it's
> > progress. FWIW, I don't think 2.10 (and above) wi
2007/5/2, Mats Bengtsson <[EMAIL PROTECTED]>:
\version "2.11.22"
\paper{ ragged-right=##t indent = #0 }
\new Score
{
\new Staff \relative c'' {
R1 \bar ":|" bes2 r2 \bar "|" bes2 r2 | \break
\override Score.BarLine #'space-alist = #'(
(time-signature . (extra-space . 0.75))
(custos . (mi
2007/5/2, Joe Neeman <[EMAIL PROTECTED]>:
> Well, I have seen that the Lilypond version 2.8.8 can easily be
> installed in the local directory, and with that, everything compiles in
> a couple of seconds with no fuss.
Yes, I can confirm that 2.10 (and 2.11) seem to use a significant amount m
can you double check for me that whether this is a new fault in .23 ?
2007/5/2, Nancho Alvarez <[EMAIL PROTECTED]>:
> I am not top posting
I have found a bug with the lyrics tie feature ( "~" in the lyrics section).
lilypond can compile it perfectly to a .ps file, but the process of
converting
> I am not top posting
I have found a bug with the lyrics tie feature ( "~" in the lyrics section).
lilypond can compile it perfectly to a .ps file, but the process of
converting it to .pdf fails. The weird thing is that typing manually the command
mentioned in the error message, the conversion w
2007/5/2, Joe Neeman <[EMAIL PROTECTED]>:
With my working copy of lilypond (on a 1.6 GHz Opteron), I have this down to
3m22.321s. That's still about 3 times slower than 2.8 but it's progress.
FWIW, I don't think 2.10 (and above) will ever be as fast as 2.8 when there
are many scores -- the newer
On Wednesday 02 May 2007 18:53, Geoffrey Hemion wrote:
> Joe Neeman wrote:
> > I recently discovered that the new page-breaking algorithm is slow when
> > there are many small scores. As a workaround, put
> > \paper {
> > #(define page-breaking optimal-page-breaks)
> > }
> > at the top of the fil
On Wednesday 02 May 2007 20:01, Arvid Grøtting wrote:
> Joe Neeman gmail.com> writes:
> > I recently discovered that the new page-breaking algorithm is slow when
> > there are many small scores.
>
> FWIW, lilypond finished processing this score in 26m37.359s on a (fairly
> new) laptop I use, using
Perfect! Thank you very much!
I'm still willing to contribute to sponsoring a bug-fix.
David
--
View this message in context:
http://www.nabble.com/average-spacing-wishes-and-note-too-close-to-barline-tf3670154.html#a10283628
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.
It turns out that the bug has already been reported and fixed, see
http://code.google.com/p/lilypond/issues/detail?id=341&can=2&q=
Since I had compiled my LilyPond version myself from the source
repository, the bug was already fixed in my version of LilyPond
when I tried your example. So, just wa
Joe Neeman gmail.com> writes:
>
> I recently discovered that the new page-breaking algorithm is slow when there
> are many small scores.
FWIW, lilypond finished processing this score in 26m37.359s on a (fairly new)
laptop I use, using version 2.11.23 on Linux (64-bit Ubuntu 7.04).
The "conver
madhg wrote:
Mats Bengtsson-4 wrote:
You can workaround your problem by increasing either the semi-fixed-space
after next-note or the left-padding of AccidentalPlacement even more,
but I'm
afraid that such a setting may look ugly in other measures where you
don't have
this particular c
Mats Bengtsson-4 wrote:
>
> As far as I can see, this is a separate bug from #242 (at least partly).
>
OK, in that case my offer to sponsor a fix doesn't apply to #242
Mats Bengtsson-4 wrote:
>
> You can workaround your problem by increasing either the semi-fixed-space
> after next-note
As far as I can see, it works well, i.e. you get a single connected arpeggio
that spans the chords in both voices.
Could you please explain in more detail what you think doesn't work.
/Mats
Damian leGassick wrote:
does not work when combined with \Change Staff
\version "2.11.22"
pianoUp
You misunderstood me. What I tried to say was that the problem you observe
has nothing to do with the average-spacing-wishes property and therefore
cannot
be solved by setting that property, no matter how many staves you have.
(However, once you have solved it for a single stave, you may still
17 matches
Mail list logo
