bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash with simultaneous-duplicating music function and \once\offset


From: Aaron Hill
Subject: Re: Crash with simultaneous-duplicating music function and \once\offset
Date: Tue, 17 Jul 2018 13:30:46 -0700
User-agent: Roundcube Webmail/1.3.6

On 2018-07-17 11:46, David Kastrup wrote:
Aaron Hill <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]