Re: repeating bar numbers and rehearsal marks in frenched scorej

[Mark Knoop]

At 10:52 on 28 Jul 2016, Mark Knoop wrote:
>At 09:59 on 28 Jul 2016, David Kastrup wrote:
>>It seems like an ad-hoc band-aid with limited utility.  I'd rather see
>>something covering more use cases.
>
>Regardless of the merits of this solution, I not sure about it
>having limited utility. Repeating a mark line is fairly common in
>modern orchestral scores and vocal/choral piano reductions, and is
>currently not achievable (whilst also removing empty staves) in
>Lilypond (please correct me if I'm wrong).
>
>Examples:
>
>- http://imslp.org/wiki/The_Dream_of_Gerontius,_Op.38_(Elgar,_Edward)
>  (Vocal Score)
>- http://imslp.org/wiki/Elektra,_Op.58_(Strauss,_Richard)
>
>>The current setup is intended mostly to cater with various ways of
>>typesetting split voices and by the user manually clearing
>>items-worth-living on the more spacious variants.
>>
>>So you'd have something like
>>voice1+voice2 in two systems : layer 0
>>voice1+voice2 in one system, split voices : layer 1
>>unisono : layer 2
>>
>>For your use case, you'd add a mark track into _each_ layer and clear
>>out its items-worth-living so that it does not keep its layer alive
>>on its own.
>>
>>Now this gets a bit combinatorially awkward since we get something
>>like
>>
>>mark+voice1+voice2 : layer 0
>>mark+voice1 : layer 1
>>mark+voice2 : layer 2
>>
>>and you need to manually mark all passages where there is only one
>>voice (clearing the items-worth-living on the voice contexts used in
>>layer 0 so that they don't keep the double layer active
>>unnecessarily).  That's clumsy for two voices, and it will become
>>worse for more.
>>
>>So while remove-layer is a reasonably workable mechanism for switching
>>out and back divisi staves (and relies on managing your
>>items-worth-living in the more divided variants to merge them as
>>feasible), it does not really map convincingly to your use case,
>
>Indeed - I couldn't find a way to make it work within the existing
>remove-layer functionality.
>
>>and I'd like to see something more general than your proposed band-aid
>>just catering for one specific additional case.
>>
>>So how should this roll?
>
>Another annoying quirk of my solution is that it highlights the
>somewhat counter-intuitive nature of the remove-layer property:
>setting it to false makes the layer invisible to the
>Keep_alive_together_engraver which actually *does* allow it to be
>removed rather than the opposite.

OK, here's a patch using only the remove-layer property with these
values:

- #f: ignored by Keep_alive_together_engraver
- -1: kept alive by any other layer
- integer != -1: current usage
- unspecified: kept alive by all but ignored layers

The prior comment at lily/keep-alive-together-engraver.cc, line 72:
"Unspecified layers are kept alive by anything else" was not quite true -
unspecified layers are not kept alive by ignored layers, i.e. those with
remove-layer = ##f.

I still wonder whether it might be more intuitive to swap the meanings
of #f and -1.

I've not included any documentation beyond the regression/example at
this stage.

-- 
Mark Knoop

0001-Keep-a-staff-alive-if-any-other-staff-in-the-group-i.patch
Description: Text Data