On 2018-07-17 11:46, David Kastrup wrote:
Aaron Hill <lilyp...@hillvisions.com> writes:
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.

As expected.

Agreed. Would this be worth documenting in some way, or is this just too contrived a scenario to care about?

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.

Try with \temporary (though avoiding the crash with the same kind of
manual copy).  Without either \temporary or \once, any preceding
override (such as another \offset) is replaced, so you see only one stem
length increase.

With the underlying crash resolved, should we also expect the same behavior with the double \offsetting? Again, as above, I am perfectly content with ignoring this if this is too esoteric.

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.

That one's the bug that my patch is supposed to, well, not fix but
lessen its consequences and giving a warning.  There is another one (a
failed assertion) that's still open.

Sounds good.  Many thanks, David!

-- Aaron Hill

_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Reply via email to