lilypond consistent crash

[Adam James Wilson]

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.

Best regards,
Adam