On 2018-07-15 20:09, Aaron Hill wrote:
Seems the custom music function is not needed to reproduce a crash.
%%%%
\version "2.19.82"
music = { \once \offset length 5 Stem 4 4 }
<< \music \music >>
%%%%
This also results in:
GNU LilyPond 2.19.82
Processing `crash.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
fish: “lilypond crash.ly” terminated by signal SIGSEGV (Address
boundary error)
David mentioned two issues: using `<<...>>` top-level and using
unpitched notes.
Consider the following not-quite-as-minimal example:
%%%%
\version "2.19.82"
music = { \once \offset length 5 Stem c'4 c'4 }
\new Staff { c'4 << \music \music >> c'4 }
%%%%
Near as I can tell, the thing that makes the difference here is the
\once. If you omit the \once (which means the stem length change
persists), then you can at least get it to compile.
I tried manually duplicating the music:
%%%%
\version "2.19.82"
music = { \once \offset length 5 Stem c'4 c'4 }
musicCopy = { \once \offset length 5 Stem c'4 c'4 }
\new Staff { c'4 << \music \musicCopy >> c'4 }
%%%%
This variant does compile, although the side-effect here is that the
stem length is twice as long. I suppose this would make sense providing
simultaneous music results in a single stem shared by the notes so that
the two \offsets stack their effects. But then that doesn't explain why
the same behavior isn't seen when omitting \once in the first example.
In that case, there is still a shared stem, but the \offset effect is
not doubled.
Based on that success, I tried to get the original approach to compile
using either music-clone or ly:music-deep-copy, but perhaps I do not
understand those functions well enough to use properly. I would have
expected that it would be possible to programmatically achieve the
equivalent to \musicCopy as in my second example, with something like
this:
%%%%
\version "2.19.82"
music = { \once \offset length 5 Stem c'4 c'4 }
\new Staff { { c'4 << \music $(music-clone music) >> c'4 } }
%%%%
It still fails in the same way.
-- Aaron Hill
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
