lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

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