[Top][All Lists]

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

Re: repeating bar numbers and rehearsal marks in frenched scorej

From: Mark Knoop
Subject: Re: repeating bar numbers and rehearsal marks in frenched scorej
Date: Thu, 28 Jul 2016 10:52:51 +0100

At 09:59 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop <address@hidden> writes:
>> At 06:21 on 28 Jul 2016, James Lowe wrote:
>>>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.
>>>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.

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).


  (Vocal Score)

>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.

Perhaps this logic could work for values of remove-layer, all dependent
on appropriate settings of items-worth-living:

- #t: layer invisible to Keep_alive_together_engraver
- #f: layer not removed unless others in group are dead (my use case)
- integer: existing usage
- '(): existing usage

If you think that could work then I'll try an implementation.

Mark Knoop

reply via email to

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