2017-07-28 1:16 GMT+02:00 Guy Stalnaker <jimmyg...@gmail.com>: > Simon, > > That was my tack -- the dirty way was to slowly comment out sections and see > what happened. It's the oddest thing. I'm writing a piano reduction mostly > from string parts, so I'm doing this: > > <lilypond> > pianoRH = { > << { ViolinI } \\ { ViolinII } >> > } > pianoLH = { > << { Violo } \\ { Cello } >> > } > </lilypond> > > As shown, did not compile. Comment out ViolinI, compiles. Add it back, > compile fails. Comment out ViolinII, compiles, add ViolinII back, compile > fails. WTH? So, I think you're right, it's some sort of memory/resource > something. > > But ... > > I replaced the ViolinI code with the original code (from the composer) AND > IT NOW COMPILES in its entirety. > > That is maddening. But, I've no time to waste on it now, and thankfully I've > little hair to pull out over it. > > Thanks for your reply, MUCH appreciated. > > Guy > > On 7/27/2017 6:06 PM, Simon Albrecht wrote: >> >> On 28.07.2017 00:55, Guy Stalnaker wrote: >>> >>> I'm not trying to figure out how to do something here. This is a code >>> file that compiled to midi/pdf output a few hours ago (last successful pdf >>> output at 4:31p CDT). >> >> >> Can you restore the file version that compiled successfully? Or is there >> any other chance of narrowing down the part of the code that’s problematic? >> There have been problems with memory that are triggered by the size of the >> score, but IIRC those had three-digit page numbers. >> >> Best, Simon
Occasionally I had smiliar problems, with files I was working on. Eventually I must have added some whitespace-characters at unfortunate place without noticing. Because it worked again after doing "Remove Trailing Whitespace" (provided by my editor). Cheers, Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user