[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lilypond consistent crash
From: |
Joe Neeman |
Subject: |
Re: lilypond consistent crash |
Date: |
Mon, 24 Sep 2007 17:47:50 +1000 |
User-agent: |
KMail/1.9.7 |
On Mon, 24 Sep 2007 03:11:27 Trevor Bača wrote:
> On 9/23/07, Adam James Wilson <address@hidden> wrote:
> > Hi folks,
> >
> > I'm pretty frustrrated at the moment - wondering if anyone has
> > exeperienced a similar problem.
> >
> > I unfortunately don't have a small snippet to describe the problem,
> > because it seems to arise from volume/complexity. . .
> >
> > Here's what I'm doing:
> >
> > I'm using a global "invisible" voice at 3/8 in all staves of my score.
> > I'm using proportional notation, strict stretching and spacing, and
> > force a line break at every 4 measures in the global voice
> >
> > I have several actual voices in different staves all barred at
> > different tempos, which are constantly changing: for example, 71 bars
> > of 3/8 in the space of 49 bars of the global voice. I'm using
> > compressMusic to accomplish this.
> >
> > Timing, barline engraver, and rehearsal marks are all on the staff
> > context, since each staff has a different tempo. At points some of
> > the barlines sync up, and then move off again.
> >
> > Since my piece has reached a certain size, lilypond will chug away at
> > the score and then simply stop, without writing .ps or .pdf files. I
> > tried with both mac os X 10.4 (PPC) and windows XP versions of
> > 2.11.32. Memory keeps getting consumed - up to 387MB in one trial -
> > and the console prints about a zillion of the following warnings
> > before quitting:
> >
> > programming error: minimise_least_squares (): Nothing to minimise
> > This means that vertical spacing is triggered
> > before line breaking
> > continuing, cross fingers
> >
> > I've sort of committed to Lily as a medium for what I'm doing - no
> > other software seems to be able to do multi-tempo proprtional
> > notation; however, I'm only a few minutes into the piece and have
> > encountered this rendering roadblock.
> >
> > Rendering the piece in chunks will not work (unless someone knows a
> > trick) because so many bars are breaking at a line break (this is what
> > I want - horizontal consistency in time as well as relative temporal
> > consistency between parts) - there are almost no places where a page
> > finishes with all parts together.
> >
> > I'm wondering if this has anything to do with the timing bug I
> > discovered whereby compressMusic doesn't compress capital-R rests
> > properly without the addition of a funky \time ratio; perhaps there
> > are other hidden problems with compressMusic?
> >
> > Any help would be greatly appreciated - I'm on a deadline (end of
> > October) to finish this piece; if a fix requires sponsorship I'm
> > willing to kick in.
>
> Hi Adam,
>
> I was just taking a break from partitioning my current inputfile due
> to this same bug whenI clicked over and saw your mail.
>
> Some time ago -- unfortunately I haven't been able to pinpoint the
> exact release -- a filesize-related rendering problem did indeed enter
> the 2.11 development releases. I opened Google #433
> (http://code.google.com/p/lilypond/issues/detail?id=433) and both Joe
> and Nicolas jumped to help.
Before you start working on a complicated workaround, you should know that
Nicolas sent a very helpful backtrace today that may have pinpointed the
problem in #433, so it might be fixed very soon now. Nevertheless, it seems
like there might be another issue here -- if the issue doesn't go away soon,
can you create a minimal example that causes the minimise_least_squares
error?
Joe