lilypond-devel
[Top][All Lists]
Advanced

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

Re: repeating bar numbers and rehearsal marks in frenched score


From: David Kastrup
Subject: Re: repeating bar numbers and rehearsal marks in frenched score
Date: Sun, 31 Jul 2016 21:21:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Mark Knoop <address@hidden> writes:

> On 29/07/16 18:09, Mark Knoop wrote:
>> I still think the easiest and most logical way to do this is with
>> the Keep_alive_together_engraver.
>>
>> Prior to the fix for issue 3518 (support for temporary divisi
>> staves), the Keep_alive_together_engraver was useful only in
>> Frenched scores, i.e. in conjunction with \RemoveEmptyStaves - one
>> doesn't need to keep things alive together if they are alive all the
>> time.
>>
>> The introduction of the VerticalAxisGroup.remove-layer property
>> created a usage of the Keep_alive_together_engraver in an
>> un-Frenched score, indeed in the current state the layer with the
>> highest score can't include \RemoveEmptyStaves as it would then
>> never appear. See attached expansion of the divisi-staves regtest.
>
> OK. Attached are two patches and a test case. The patches are two
> alternate methods of approaching the problem.
>
> Keep a staff alive with multiple layers
> ---------------------------------------
>
> This changes the remove-layer property to number-or-pair? such that a
> list of values can be specified. The layer will remain alive with any
> other layer whose remove-layer value is in the list.

If one can specify more than one remove-layer, what layer does a staff
belong to?  If there is no longer numerical order, how are cycles
avoided?

> Keep a staff alive until it is alone in the group
> -------------------------------------------------
>
> This patch uses a new boolean property remove-orphan which keeps the
> staff alive while any other is alive.

What if there are multiple orphans?  And how does this differ from the
normal behavior in a keep-alive group?

All in all, I am more sympathetic to the list approach (which looks more
generic), it is just that I see a lot of potential for paradoxes or even
hangs.  I may be wrong.

-- 
David Kastrup



reply via email to

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