lilypond-user
[Top][All Lists]
Advanced

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

Issue with make-dead-when (divisi, hara_kiri)


From: Saul Tobin
Subject: Issue with make-dead-when (divisi, hara_kiri)
Date: Sun, 28 Oct 2018 14:22:22 -0700

Hi all,

Not sure if this should be on the User mailing list or one of the others.

The attached code replicates a strange behavior I have encountered several different times, where seemingly random and irrelevant musical details cause staves to incorrectly disappear when using the divisi snippet I posted a few months ago. I also tested this with variants of Thomas Morley's version of the snippet, so I'm convinced it's not anything to do with the snippet itself.

In my attached example, notice that the Oboe 2 staff disappears when it shouldn't, but if you remove the hairpin from the flute part, the Oboe 2 staff reappears. I believe that this is caused by the Oboe 2 staff having 'make-dead-when set to the combined staff, which itself has 'make-dead-when set to Oboe 1. Hara_kiri_group_spanner::request_suicide checks each foe staff for is_live and request_suicide_alone, but not request_suicide (to avoid infinite loops, I guess). So if Oboe1+2 becomes dead due to 'make-dead-when, when on its own it would have stayed alive, it may either appear alive or dead to Oboe 2, depending on which staff happens to be evaluated first.

To avoid this race condition, one has to avoid setting 'keep-dead-when to point to other staves that themselves have 'keep-dead-when set. In other words, for some staves to be masters, others to be slaves. Which is probably a good idea anyway, but it leaves a gap in functionality when it comes to 3+ stave divisi. For 3 staves, you have:

1+2+3:  Alive if BOTH 1 and 3 are dead
1+2: Alive if 1 is dead AND 3 is alive
2+3: Alive if 1 is alive AND 3 is dead
1: Master staff
2: Alive if BOTH 1 and 3 are alive
3: Master staff

With the semantics of the existing 'make-dead-when interface, this is doable by making, for instance, 1+2 and 2+3 dead whenever 1+2+3 is alive, but as I noticed, this type of inter-dependency leads to unpredictable behavior. A better way forward would be to expand the 'make-dead-when mechanism to support a complete variety of logical conditions, such as ALL vs. ANY and combinations of alive and dead conditions.

Saul

Attachment: bugtest.ly
Description: Text Data


reply via email to

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