Re: repeating bar numbers and rehearsal marks in frenched score

[David Kastrup]

Mark Knoop <address@hidden> writes:

> Hi James,
>
> At 06:21 on 28 Jul 2016, James Lowe wrote:
>>Hello Mark,
>>
>>On 27/07/16 17:39, Mark Knoop wrote:
>>> Once again further to this thread (see below) I've attempted a patch
>>> (attached) to the Keep_alive_together_engraver which makes this
>>> work, at least for my use case. There might well be a better
>>> approach, feedback would be appreciated.
>>>
>>> Possibly the keep-alive-with-id property should be a string (or list)
>>> instead of an integer.
>>>
>>> I don't have an account on the issue tracker and so haven't used the
>>> git-cl script.
>>>
>>> Regards, Mark  
>>
>>Is this for an existing issue or is there none as yet for the problem 
>>that this patch is for?
>
> AFAIK there is no existing issue for this feature, although it has been
> discussed on the user list from time to time.

It seems like an ad-hoc band-aid with limited utility.  I'd rather see
something covering more use cases.  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, 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?

-- 
David Kastrup