repeating bar numbers and rehearsal marks in frenched score

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
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

At 11:43 on 26 Jul 2016, Mark Knoop wrote:

>Further to this thread from 2013
>(https://lists.gnu.org/archive/html/lilypond-user/2013-09/msg00857.html)
>I've still not come up with a satisfactory method of duplicating a
>dedicated BarNumber/RehearsalMark context at two or more vertical
>positions in a frenched score. The context should only stay alive only
>while one or more Staff contexts are alive within the same StaffGroup.
>
>I was hoping to solve this by using the newer property
>VerticalAxisGroup.remove-layer introduced by David Kastrup in 2014 as a
>solution for issue 3518. However I can only get this to solve one
>problem - that of making the instrument staves invisible to the
>Keep_alive_together_engraver.
>
>Is there any way that the VerticalAxisGroup.keep-alive-with array can
>be set directly in scheme?
>
>%%%%%%%%%%%%%
>\version "2.19.45"
>bars = \repeat unfold 12 { \mark \default R1*2 }
>winds = \repeat unfold 96 { c''4 }
>brass = \repeat unfold 24 { R1 }
>brasstwo = { \repeat unfold 12 c'1 \repeat unfold 12 { R1 } }
>strings = \repeat unfold 192 { c''8 }
>#(set-global-staff-size 16)
>
>\layout {
>  \context {
>    \Dynamics
>    \consists Mark_engraver
>    \consists Bar_number_engraver
>  }
>  \context {
>    \Staff
>    \RemoveEmptyStaves
>  }
>  \context {
>    \Score
>    \remove Mark_engraver
>    \remove Bar_number_engraver
>  }
>}
>
>\markup "remove-layer unset for all => bars context behaves correctly,
>but b1 staff still alive in 2nd system when we want it dead"
>\score {
>  <<
>    \new Dynamics { \bars }
>    \new Staff = "winds" { \winds }
>    \new StaffGroup \with {
>      \consists Keep_alive_together_engraver
>    } <<
>      \new Dynamics \with {
>        keepAliveInterfaces = #'()
>        \override VerticalAxisGroup.remove-empty = ##t
>        \override RehearsalMark.color = #red
>      } { \bars }
>      \new Staff = "brass" \with {
>        shortInstrumentName = "b1"
>      } { \brass }
>      \new Staff = "brasstwo" \with {
>        shortInstrumentName = "b2"
>      } { \brasstwo }
>    >>  
>    \new Dynamics { \bars }
>    \new Staff = "strings" { \strings }
>  >>  
>}
>
>\markup "remove-layer bars=unset or '() or 1 or #f, b1=#f, b2=#f => b1
>and b2 staves behave correctly, but bars context dies in 2nd system"
>\score {
>  <<
>    \new Dynamics { \bars }
>    \new Staff = "winds" { \winds }
>    \new StaffGroup \with {
>      \consists Keep_alive_together_engraver
>    } <<
>      \new Dynamics \with {
>        keepAliveInterfaces = #'()
>        \override VerticalAxisGroup.remove-empty = ##t
>        \override RehearsalMark.color = #red
>        %\override VerticalAxisGroup.remove-layer = 1
>        %\override VerticalAxisGroup.remove-layer = #'()
>        %\override VerticalAxisGroup.remove-layer = ##f
>      } { \bars }
>      \new Staff = "brass" \with {
>        \override VerticalAxisGroup.remove-layer = ##f
>      } { \brass }
>      \new Staff = "brasstwo" \with {
>        \override VerticalAxisGroup.remove-layer = ##f
>      } { \brasstwo }
>    >>  
>    \new Dynamics { \bars }
>    \new Staff = "strings" { \strings }
>  >>  
>}
>
>--
>Mark Knoop
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-Keep-a-staff-alive-if-a-staff-with-the-same-id-is-al.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

James Lowe
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?

Regards

James

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
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.

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
Mark Knoop <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched scorej

Mark Knoop-4
At 09:59 on 28 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> 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).

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.

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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched scorej

Mark Knoop-4
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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-Keep-a-staff-alive-if-any-other-staff-in-the-group-i.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched scorej

David Kastrup
Mark Knoop <[hidden email]> writes:

> 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

Isn't that the same as '() ?

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

Ugh, this is a bit too random.  It would probably make more sense to use
number-or-symbol? here and then assign various symbols to various
behaviors.

At any rate, I think the principal problem is that the
Keep_alive_together_engraver is desired to keep the marks context alive
with _either_ of the two voices under it.  That would sound like we
should have some way of grouping the marks context with the
_StaffGroup_ rather than the individual contexts.

So should the Keep_alive_together_engraver stop at a VerticalAlignment?
If you want to keep together the contexts in a vertical alignment (like
a StaffGroup), you could still add another Keep_alive_together_engraver
in the context carrying the Vertical_alignment_engraver.

Basically, we would add the hara-kiri-interface to VerticalAlignment as
well?  Something like that?

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
At 17:43 on 28 Jul 2016, David Kastrup wrote:
>Mark Knoop <[hidden email]> writes:
>> 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
>
>Isn't that the same as '() ?

Well no, because of the next paragraph...

>> 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.
>
>Ugh, this is a bit too random.

Seems pretty random to me at the moment, having to set a property
called "remove-layer" to false in order to remove the layer...

>It would probably make more sense to use number-or-symbol? here and
>then assign various symbols to various behaviors.

I thought of that option, but just wanted to get the behavior working
first before continuing down this path.

>At any rate, I think the principal problem is that the
>Keep_alive_together_engraver is desired to keep the marks context alive
>with _either_ of the two voices under it.  That would sound like we
>should have some way of grouping the marks context with the
>_StaffGroup_ rather than the individual contexts.
>
>So should the Keep_alive_together_engraver stop at a VerticalAlignment?
>If you want to keep together the contexts in a vertical alignment (like
>a StaffGroup), you could still add another Keep_alive_together_engraver
>in the context carrying the Vertical_alignment_engraver.

If I understand this correctly it would seem to be a more intrusive and
less backward compatible change. And I have no idea how to implement
this.

>Basically, we would add the hara-kiri-interface to VerticalAlignment as
>well?  Something like that?

How would this be done? Just by adding the interface and Y-extent calls
in define-grobs.scm?

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
Mark Knoop <[hidden email]> writes:

> At 17:43 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop <[hidden email]> writes:
>>> 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
>>
>>Isn't that the same as '() ?
>
> Well no, because of the next paragraph...
>
>>> 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.
>>
>>Ugh, this is a bit too random.
>
> Seems pretty random to me at the moment, having to set a property
> called "remove-layer" to false in order to remove the layer...
>
>>It would probably make more sense to use number-or-symbol? here and
>>then assign various symbols to various behaviors.
>
> I thought of that option, but just wanted to get the behavior working
> first before continuing down this path.
>
>>At any rate, I think the principal problem is that the
>>Keep_alive_together_engraver is desired to keep the marks context alive
>>with _either_ of the two voices under it.  That would sound like we
>>should have some way of grouping the marks context with the
>>_StaffGroup_ rather than the individual contexts.
>>
>>So should the Keep_alive_together_engraver stop at a VerticalAlignment?
>>If you want to keep together the contexts in a vertical alignment (like
>>a StaffGroup), you could still add another Keep_alive_together_engraver
>>in the context carrying the Vertical_alignment_engraver.
>
> If I understand this correctly it would seem to be a more intrusive and
> less backward compatible change.

I'm not sure that backward compatibility would be affected all that
much.  This seems like something mainly affecting the
Keep_alive_together_engraver in complex situations unlikely to occur
previously.

> And I have no idea how to implement this.
>
>>Basically, we would add the hara-kiri-interface to VerticalAlignment as
>>well?  Something like that?
>
> How would this be done? Just by adding the interface and Y-extent calls
> in define-grobs.scm?

No, this would be a more intrusive change likely involving the C++
layer.  I'm not asking you to do this but rather whether this avenue
sounds like fitting your (and the general) problem space well enough
that it would be worthwhile to pursue.

I'm somewhat fuzzy about the semantics.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
At 19:49 on 28 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> At 17:43 on 28 Jul 2016, David Kastrup wrote:
>>>At any rate, I think the principal problem is that the
>>>Keep_alive_together_engraver is desired to keep the marks context
>>>alive with _either_ of the two voices under it.  That would sound
>>>like we should have some way of grouping the marks context with the
>>>_StaffGroup_ rather than the individual contexts.
>>>
>>>So should the Keep_alive_together_engraver stop at a
>>>VerticalAlignment? If you want to keep together the contexts in a
>>>vertical alignment (like a StaffGroup), you could still add another
>>>Keep_alive_together_engraver in the context carrying the
>>>Vertical_alignment_engraver.
>>
>> And I have no idea how to implement this.
>>
>>>Basically, we would add the hara-kiri-interface to VerticalAlignment
>>>as well?  Something like that?
>>
>> How would this be done? Just by adding the interface and Y-extent
>> calls in define-grobs.scm?
>
>No, this would be a more intrusive change likely involving the C++
>layer.  I'm not asking you to do this but rather whether this avenue
>sounds like fitting your (and the general) problem space well enough
>that it would be worthwhile to pursue.

I find that difficult to answer since I don't fully understand what the
user end code for this method would be.

I'm also unclear as to why you feel that this is unsuitable to be done
by the Keep_alive_together_engraver without further nesting. After all,
the documentation for this engraver states:

    These spanners are then tied together so that one will be removed
    only if all are removed.

which fairly precisely describes the use case. To me this seems a fairly
logical extension of the introduction of the remove-layer property.

Might you consider a further reworking of my approach using some
well-chosen symbol names for remove-layer? Perhaps:

- #removable: layer ignored by Keep_alive_together_engraver
- #alive-while-any-other: layer only removed if all others are dead
- integer: existing usage
- '(): existing usage

Thanks, M

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
Mark Knoop <[hidden email]> writes:

> I'm also unclear as to why you feel that this is unsuitable to be done
> by the Keep_alive_together_engraver without further nesting. After all,
> the documentation for this engraver states:
>
>     These spanners are then tied together so that one will be removed
>     only if all are removed.

Your use case desired to have staves removed without consideration of
whether the mark line is removed, and have the mark line removed only if
all staves are removed.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
At 21:03 on 28 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> I'm also unclear as to why you feel that this is unsuitable to be
>> done by the Keep_alive_together_engraver without further nesting.
>> After all, the documentation for this engraver states:
>>
>>     These spanners are then tied together so that one will be removed
>>     only if all are removed.  
>
>Your use case desired to have staves removed without consideration of
>whether the mark line is removed, and have the mark line removed only
>if all staves are removed.

How is this so conceptually dissimilar to the divisi-staves situation
which introduced the remove-layer property?

Staves are already removeable without consideration of other contexts
by setting remove-layer = ##f. The only change is that a specified
context can be retained throughout the normal life of the group.

I'm sorry, I am trying to progress this and respond to your
suggestions, but it would be nice to receive some proper criticism of
my (working) code which amounts to more than just "I don't like it".

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

tisimst
Mark, et al,

On Thu, Jul 28, 2016 at 1:36 PM, Mark Knoop-4 [via Lilypond] <[hidden email]> wrote:
At 21:03 on 28 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> I'm also unclear as to why you feel that this is unsuitable to be
>> done by the Keep_alive_together_engraver without further nesting.
>> After all, the documentation for this engraver states:
>>
>>     These spanners are then tied together so that one will be removed
>>     only if all are removed.  
>
>Your use case desired to have staves removed without consideration of
>whether the mark line is removed, and have the mark line removed only
>if all staves are removed.
How is this so conceptually dissimilar to the divisi-staves situation
which introduced the remove-layer property?

Staves are already removeable without consideration of other contexts
by setting remove-layer = ##f. The only change is that a specified
context can be retained throughout the normal life of the group.

I'm sorry, I am trying to progress this and respond to your
suggestions, but it would be nice to receive some proper criticism of
my (working) code which amounts to more than just "I don't like it".

Forgive me if this is the wrong place to ask this question, but can the new code handle nested situations?

For example, let's say we have four horns. These may appear on their own staff, they may appear on a combined staff (e.g., "Horns 1 & 2"), and they may appear on a single staff together. The divisi-staves example works wonderfully for a single parent-child situation, but using the 'keepAliveInterfaces as the trigger doesn't seem to allow you to have more nested levels. Here's a complete compiling example. I tried to extend the divisi-staves code to allow for this multi-level nesting, but all permutations failed for me. Here's one example:

%%%%%%%%%

\version "2.19.13"

\header {
  texidoc = "The @code{VerticalAxisGroup.remove-layer}
property can be used for typesetting temporary divisi staves where
the switch to split staves is done only at line breaks such that all
complex passages are rendered in separate staves."
}

boring = \set Staff.keepAliveInterfaces = #'()
tricky = \unset Staff.keepAliveInterfaces

violI=\relative c'' {
  \boring \repeat unfold 50 c4
  \tricky <c g'>2
  \boring \repeat unfold 48 c4
  \tricky <c g'>2
  \boring \repeat unfold 98 c4
  \bar "|."
}

violII=\relative g' {
  \boring \repeat unfold 100 g4
  \tricky <g d'>2
  \boring \repeat unfold 98 g4
  \bar "|."
}

violIII=\relative e' {
  \boring \repeat unfold 100 e4
  \tricky <e b'>2
  \boring \repeat unfold 48 e4
  \tricky <e b'>2
  \boring \repeat unfold 48 e4
  \bar "|."
}

violIV=\relative c' {
  \boring \repeat unfold 100 c4
  \tricky <c g'>2
  \boring \repeat unfold 98 c4
  \bar "|."
}

\score {
  \new StaffGroup \with { 
    \consists "Keep_alive_together_engraver" 
  } <<
    \new StaffGroup \with { 
      \consists "Keep_alive_together_engraver" 
      \override VerticalAxisGroup.remove-layer = 1
      \remove System_start_delimiter_engraver
    } <<
        \new Staff \with { 
          instrumentName = "Violin I"
          shortInstrumentName = "V I"
          \override VerticalAxisGroup.remove-empty = ##t
          \override VerticalAxisGroup.remove-first = ##t
          \override VerticalAxisGroup.remove-layer = 1
        } \violI
        \new Staff \with { 
          instrumentName = "Violin II"
          shortInstrumentName = "V II"
          \override VerticalAxisGroup.remove-empty = ##t
          \override VerticalAxisGroup.remove-first = ##t
          \override VerticalAxisGroup.remove-layer = 1
        } \violII
        \new Staff \with { 
          instrumentName = "Violins I&II"
          shortInstrumentName = "V I&II"
          \override VerticalAxisGroup.remove-layer = 2
        } << \violI \\ \violII  >>
    >>
    \new StaffGroup \with { 
      \consists "Keep_alive_together_engraver" 
      \override VerticalAxisGroup.remove-layer = 1
      \remove System_start_delimiter_engraver
    } <<
        \new Staff \with { 
          instrumentName = "Violin III"
          shortInstrumentName = "V III"
          \override VerticalAxisGroup.remove-empty = ##t
          \override VerticalAxisGroup.remove-first = ##t
          \override VerticalAxisGroup.remove-layer = 1
        } \violIII
        \new Staff \with { 
          instrumentName = "Violin IV"
          shortInstrumentName = "V IV"
          \override VerticalAxisGroup.remove-empty = ##t
          \override VerticalAxisGroup.remove-first = ##t
          \override VerticalAxisGroup.remove-layer = 1
        } \violIV
        \new Staff \with { 
          instrumentName = "Violins III&IV"
          shortInstrumentName = "V III&IV"
          \override VerticalAxisGroup.remove-layer = 2
        } << \violIII \\ \violIV  >>
    >>
    \new Staff \with { 
      instrumentName = "Violins"
      shortInstrumentName = "V I-IV"
      \override VerticalAxisGroup.remove-layer = 2
    } << \violI \\ \violII \\ \violIII \\ \violIV >>
  >>
  \layout {
    short-indent = 2\cm
    indent = 3\cm
  }
}

%%%%%%%%%

Here are some other scenarios I tried, but failed with:
1. A single StaffGroup contains seven Staff contexts: four individuals, two paired staves, and one combined staff. Each individual Staff had a 'remove-layer value of 1, each paired Staff had a 'remove-layer value of 2 and the combined Staff had a 'remove-layer value of 3. This seems like the ideal situation since it has the simplest structure.
2. Adding/removing \RemoveAllEmptyStaves to the paired Staff and StaffGroups
3. Adding/removing \consists "Keep_alive_together_engraver" to the paired StaffGroups

No matter what I tried, I would either get the individual staves and the combined staff or I'd get the paired staves and the combined staff or the individual staves and the paired staves, but never all three. My guess is that nesting makes things much more complicated because of the increase in pair multiplicity. Looking at the VerticalAxisGroup properties, I see the 'keep-alive-with and 'make-dead-with properties, which seem like they could do the trick, but I haven't a clue how to get the Staff grobs so I can set them. Ideally, the nesting might appear like this (using those properties):

(Top-most combined staff): Staff.make-dead-with = #'(pair-one-staff pair-two-staff)
(Middle paired staff): Staff.make-dead-with = #'(individual-one-staff indvidual-two-staff)
(Bottom individual staff): Staff.keep-alive-with = #'(individual-two-staff)

where pair-one-staff, pair-two-staff, indvidual-one-staff, and individual-two-staff are the grob variables of those Staff contexts. But how to get them and make those connections? Or, am I misunderstanding how these work? 

Thanks for hearing me out and thanks for all you both do!

Best,
Abraham
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
In reply to this post by Mark Knoop-4
Mark Knoop <[hidden email]> writes:

> At 21:03 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop <[hidden email]> writes:
>>> I'm also unclear as to why you feel that this is unsuitable to be
>>> done by the Keep_alive_together_engraver without further nesting.
>>> After all, the documentation for this engraver states:
>>>
>>>     These spanners are then tied together so that one will be removed
>>>     only if all are removed.  
>>
>>Your use case desired to have staves removed without consideration of
>>whether the mark line is removed, and have the mark line removed only
>>if all staves are removed.
>
> How is this so conceptually dissimilar to the divisi-staves situation
> which introduced the remove-layer property?

The staves are also removed without consideration whether the other
staff is removed.  While the mark line needs to watch both staff lines.

> I'm sorry, I am trying to progress this and respond to your
> suggestions, but it would be nice to receive some proper criticism of
> my (working) code which amounts to more than just "I don't like it".

It makes stuff more complex rather than simpler while adding only quite
specific use cases rather than a new class of problems.  I am searching
for something with a better payoff in terms of opening obvious solutions
for regularly occuring problems.  remove-layer is a low-level mechanism
for dealing comparatively straightforwardly with typical divisi
problems.  What you are looking for, however, is a class of simple
omission problems.  Maybe we can solve this completely differently?
Like using "alignAboveContext"  being given the StaffGroup context name?
And just squashing it when the StaffGroup to align above is missing?

That would appear to match the problem space well enough again.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
In reply to this post by tisimst
At 13:08 on 28 Jul 2016, tisimst wrote:

>Forgive me if this is the wrong place to ask this question, but can
>the new code handle nested situations?
>
>For example, let's say we have four horns. These may appear on their
>own staff, they may appear on a combined staff (e.g., "Horns 1 & 2"),
>and they may appear on a single staff together. The divisi-staves
>example works wonderfully for a single parent-child situation, but
>using the 'keepAliveInterfaces as the trigger doesn't seem to allow
>you to have more nested levels. Here's a complete compiling example. I
>tried to extend the divisi-staves code to allow for this multi-level
>nesting, but all permutations failed for me. Here's one example:
I don't think you need nesting for this, but you need to find a way to
specify the boring/tricky nature of the material at each remove-layer.
Attached is I think what you want.

Ideally we wouldn't be moving pitches to the violIandIItrickyness
and violIIIandIVtrickyness variables, you could try setting
keepAliveInterfaces to something else to trigger "interest" instead.

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

tisimst.ly (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
In reply to this post by David Kastrup
At 22:09 on 28 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> I'm sorry, I am trying to progress this and respond to your
>> suggestions, but it would be nice to receive some proper criticism of
>> my (working) code which amounts to more than just "I don't like
>> it".  
>
>It makes stuff more complex rather than simpler while adding only quite
>specific use cases rather than a new class of problems.  I am searching
>for something with a better payoff in terms of opening obvious
>solutions for regularly occuring problems.  remove-layer is a
>low-level mechanism for dealing comparatively straightforwardly with
>typical divisi problems.  

OK, I disagree, but must accept your decision.

>What you are looking for, however, is a
>class of simple omission problems.  Maybe we can solve this completely
>differently? Like using "alignAboveContext"  being given the
>StaffGroup context name? And just squashing it when the StaffGroup to
>align above is missing?
>
>That would appear to match the problem space well enough again.

OK, this could be another approach. But this would require a new
property to request this behaviour. Would this then happen in
Vertical_align_engraver::acknowledge_axis_group ? Only inserting the
grob if the before_grob is there?

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
Mark Knoop <[hidden email]> writes:

> At 22:09 on 28 Jul 2016, David Kastrup wrote:
>>Mark Knoop <[hidden email]> writes:
>>> I'm sorry, I am trying to progress this and respond to your
>>> suggestions, but it would be nice to receive some proper criticism of
>>> my (working) code which amounts to more than just "I don't like
>>> it".  
>>
>>It makes stuff more complex rather than simpler while adding only quite
>>specific use cases rather than a new class of problems.  I am searching
>>for something with a better payoff in terms of opening obvious
>>solutions for regularly occuring problems.  remove-layer is a
>>low-level mechanism for dealing comparatively straightforwardly with
>>typical divisi problems.  
>
> OK, I disagree, but must accept your decision.

Shrug.  I don't have any veto power here.  Feel free to get other
opinions.  I'm the one most likely stuck with maintaining the code,
others are most likely to have to maintain the corresponding
documentation.

>>What you are looking for, however, is a
>>class of simple omission problems.  Maybe we can solve this completely
>>differently? Like using "alignAboveContext"  being given the
>>StaffGroup context name? And just squashing it when the StaffGroup to
>>align above is missing?
>>
>>That would appear to match the problem space well enough again.
>
> OK, this could be another approach. But this would require a new
> property to request this behaviour.

I don't see why.  Care to explain?

> Would this then happen in
> Vertical_align_engraver::acknowledge_axis_group ? Only inserting the
> grob if the before_grob is there?

I haven't yet looked at the code.  However, I think that suicides happen
a lot later than that and the point would be to track suicides.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
At 11:26 on 29 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> At 22:09 on 28 Jul 2016, David Kastrup wrote:
>>>What you are looking for, however, is a
>>>class of simple omission problems.  Maybe we can solve this
>>>completely differently? Like using "alignAboveContext"  being given
>>>the StaffGroup context name? And just squashing it when the
>>>StaffGroup to align above is missing?
>>>
>>>That would appear to match the problem space well enough again.
>>
>> OK, this could be another approach. But this would require a new
>> property to request this behaviour.
>
>I don't see why.  Care to explain?

Currently this:

\score {
  <<
    \new Staff = "staffone" \with {
      alignAboveContext = "keepstaffonealive"
      \override NoteHead.color = #red
    } { \repeat unfold 120 c'4 }
    \new StaffGroup = "keepstaffonealive" <<
      \new Staff = "stafftwo" \with {
        \RemoveEmptyStaves
        \override NoteHead.color = #blue
      } { \repeat unfold 20 c'4 R1*20 \repeat unfold 20 c'4 }
    >>
    \new Staff = "staffthree" \with {
    } { \repeat unfold 120 c'4 }
  >>
}

keeps staffone alive all the time. The desired behaviour is that
staffone is only alive while stafftwo is also alive (via the proxy of
the StaffGroup). If just specifying alignAboveContext kills staffone
when that context goes away, surely that's a fairly major change of
behaviour. But perhaps I have misunderstood your approach.

>> Would this then happen in
>> Vertical_align_engraver::acknowledge_axis_group ? Only inserting the
>> grob if the before_grob is there?
>
>I haven't yet looked at the code.  However, I think that suicides
>happen a lot later than that and the point would be to track suicides.

I'll have a look and see what I can find.

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

David Kastrup
Mark Knoop <[hidden email]> writes:

> At 11:26 on 29 Jul 2016, David Kastrup wrote:
>>Mark Knoop <[hidden email]> writes:
>>> At 22:09 on 28 Jul 2016, David Kastrup wrote:
>>>>What you are looking for, however, is a
>>>>class of simple omission problems.  Maybe we can solve this
>>>>completely differently? Like using "alignAboveContext"  being given
>>>>the StaffGroup context name? And just squashing it when the
>>>>StaffGroup to align above is missing?
>>>>
>>>>That would appear to match the problem space well enough again.
>>>
>>> OK, this could be another approach. But this would require a new
>>> property to request this behaviour.
>>
>>I don't see why.  Care to explain?
>
> Currently this:
>
> \score {
>   <<
>     \new Staff = "staffone" \with {
>       alignAboveContext = "keepstaffonealive"
>       \override NoteHead.color = #red
>     } { \repeat unfold 120 c'4 }
>     \new StaffGroup = "keepstaffonealive" <<
>       \new Staff = "stafftwo" \with {
>         \RemoveEmptyStaves
>         \override NoteHead.color = #blue
>       } { \repeat unfold 20 c'4 R1*20 \repeat unfold 20 c'4 }
>     >>
>     \new Staff = "staffthree" \with {
>     } { \repeat unfold 120 c'4 }
>   >>
> }
>
> keeps staffone alive all the time. The desired behaviour is that
> staffone is only alive while stafftwo is also alive (via the proxy of
> the StaffGroup). If just specifying alignAboveContext kills staffone
> when that context goes away, surely that's a fairly major change of
> behaviour. But perhaps I have misunderstood your approach.

Hm, so your take is that alignAboveContext is more for establishing
order rather than a connection to the particular named context.  Maybe.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop-4
At 14:11 on 29 Jul 2016, David Kastrup wrote:

>Mark Knoop <[hidden email]> writes:
>> At 11:26 on 29 Jul 2016, David Kastrup wrote:  
>>>Mark Knoop <[hidden email]> writes:  
>>>> At 22:09 on 28 Jul 2016, David Kastrup wrote:  
>>>>>What you are looking for, however, is a
>>>>>class of simple omission problems.  Maybe we can solve this
>>>>>completely differently? Like using "alignAboveContext"  being given
>>>>>the StaffGroup context name? And just squashing it when the
>>>>>StaffGroup to align above is missing?
>>>>>
>>>>>That would appear to match the problem space well enough again.  
>>>>
>>>> OK, this could be another approach. But this would require a new
>>>> property to request this behaviour.  
>>>
>>>I don't see why.  Care to explain?  
>>
>> Currently this:
>>
>> \score {
>>   <<
>>     \new Staff = "staffone" \with {
>>       alignAboveContext = "keepstaffonealive"
>>       \override NoteHead.color = #red
>>     } { \repeat unfold 120 c'4 }
>>     \new StaffGroup = "keepstaffonealive" <<
>>       \new Staff = "stafftwo" \with {
>>         \RemoveEmptyStaves
>>         \override NoteHead.color = #blue
>>       } { \repeat unfold 20 c'4 R1*20 \repeat unfold 20 c'4 }  
>>     >>  
>>     \new Staff = "staffthree" \with {
>>     } { \repeat unfold 120 c'4 }  
>>   >>  
>> }
>>
>> keeps staffone alive all the time. The desired behaviour is that
>> staffone is only alive while stafftwo is also alive (via the proxy of
>> the StaffGroup). If just specifying alignAboveContext kills staffone
>> when that context goes away, surely that's a fairly major change of
>> behaviour. But perhaps I have misunderstood your approach.  
>
>Hm, so your take is that alignAboveContext is more for establishing
>order rather than a connection to the particular named context.  Maybe.

The documentation seems pretty clear on this:

http://lilypond.org/doc/v2.19/Documentation/notation/context-layout-order

http://lilypond.org/doc/v2.19/Documentation/learning/satb-with-aligned-contexts

http://lilypond.org/doc/v2.19/Documentation/learning/size-of-objects#index-alignAboveContext-property_002c-example

--
Mark Knoop

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
12