Kieren MacMillan <[email protected]> writes: > A little more that might help: > > 1. My skeleton score has a bunch of partcombine-d staves (all empty), > and a single vocal staff (with music). > > 2. The vocal staff uses David Nalesnik’s > text-spanner-inner-texts. This works perfectly in the piano-vocal > score of the same piece (i.e., without the partcombine-d instrumental > staves). > > 3. If I comment out all partcombine-d content AND the > text-spanner-inner-texts code, the score compiles without error. If I > leave in the text-spanner-inner-texts code OR a few partcombine-d > staves, the score compiles without error. Only if I try to have both > the text-spanner-inner-texts code AND one or more partcombine-d staves > does the compile fail. > > 4. The second last line of the log, e.g., >> ERROR: Wrong type (expecting exact integer): Timing > changes depending on how much I’ve commented out or left in. The > ‘Timing’ might say ‘DrumVoice’ or ‘Staff’ or ‘VaticanaVoice’, etc. I > have not figured out a pattern. > > Thanks for any hints/help.
You have identified one tangible component likely involved with the problem and you only mention it by name. Even if only a single person is interested in answering, the effort for him to dig up some version possibly corresponding with the one you use will already be higher than for you to just include what you are talking about. It also sounds as if you are reasonably close to figuring out how to create an actual minimal example using just the specified code and no other includes. The possibilities for tracking this down will be either staring at the text-spanner-inner-texts source code until one notices something fishy, or it will include debugging actual code. The kind of no-rhyme-no-reason behavior you describe looks like a problem involving garbage collection. That can not actually be triggered by Scheme code alone without having some C++ code involved as well. That makes it less likely that dry inspection without actual debugging will uncover the problem. The last lines of the traceback 243: 13 [ly:book-process #<Book> #< Output_def> ...] In unknown file: ?: 14* [# #] ?: 15* [# # #] ?: 16* [#<Callback0_wrapper> #<Translator Auto_beam_engraver >] point to code likely introduced in version 2.19.55 as commit 6d1c5d25389afa6dbbfb4722df3732e764cbbf2e Author: David Kastrup <[email protected]> Date: Fri Jan 27 13:27:03 2017 +0100 Issue 1375/1: Let Translator constructor take a Context argument This is the first step towards constructing rather than cloning translators when creating contexts. On its own, it does not make sense, but the change is large and mostly mechanical, so keeping it separate from the actually difficult parts makes sense. This has changed internal organization of translators including protection of some translator internals. David's work often has to mess with internals (for lack of working interfaces allowing similar extensions by regular means), so it may well be that it leaves them in a state where the assumptions underlying the internal translator organization are no longer met in a manner the current translator code expects. That's just guessing, of course. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
