lilypond-user
[Top][All Lists]
Advanced

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

Re: New snippet: remove staff if another is alive (for wind divisi)


From: Thomas Morley
Subject: Re: New snippet: remove staff if another is alive (for wind divisi)
Date: Wed, 8 Aug 2018 22:21:57 +0200

2018-08-08 15:25 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> 2018-08-07 21:42 GMT+02:00 David Kastrup <address@hidden>:
>>> Thomas Morley <address@hidden> writes:
>>>
>>>> 2018-08-07 20:28 GMT+02:00 David Kastrup <address@hidden>:
>>>>> Thomas Morley <address@hidden> writes:
>>>>
>>>>>>> Ok, let me chime in: I've basically developed some of the low-level
>>>>>>> mechanisms for divisi staves.
>>>>>>
>>>>>> You mean that 'make-dead-when stuff?
>>>>>
>>>>> Well, that's the internal part of the low end.  But it's usually driven
>>>>> by the remove-layer property.  You are not actually using it?
>>>>
>>>> Nope.
>>>> I'll have a closer look at it, though.
>>>
>>> Maybe it's a failure.  It may well have problems scaling since it
>>> creates a single hierarchy.  I know that one tenet or inspiration for
>>> that kind of numerical hierarchy was that it was reasonably certain to
>>> avoid creating strange loops.
>>
>>
>> I've started trying to understand 'remove-layer by reading the IR,
>> doc-strings and playing with /input/regression/divisi-staves.ly
>> Afaik no further documentation exists.
>>
>> As mentioned earlier in this thread I think divisi-Staffs should be
>> controled from inside themselves, not from the content for the single
>> voices.
>
> What does "from inside themselves" even mean?  You need three different
> versions: what should appear in the non-divided staves, what should
> appear in the upper staff of a division, what should appear in the lower
> staff of a division.  All of these need to be present in source, likely
> employing the help of tags.
>
> I think one problem here may be what we consider "divisi staves":
> I suspect that your approach considers two voices to be identical
> outside of a divisi stave passage.  However, divisi passages rarely
> require divisi staves unless the division becomes too complex to be
> representable in a single staff.
>
> So for me the principal division is not as much one of unison
> vs. divided rather than monophonic vs polyphonic (the former usually
> lends itself to single-staff notation reasonably well).  Which means
> that the content in "does not need divisi staves" passages still
> fundamentally contains three different versions to work with rather than
> a single one.
>
>> Thus I changed the regtest like below.
>> While it works starting with single Staffs, switching to divisi and
>> back later, from a divisiVoice
>> It fails the other way round, i.e. single Staffs are never printed.
>>
>> switchOff = \set Staff.keepAliveInterfaces = #'()
>> switchOn = \unset Staff.keepAliveInterfaces
>>
>> violI=\relative d' {
>>   \repeat unfold 44 d4
>>   <d g'>2
>>   \repeat unfold 58 d4
>>   \bar "|."
>> }
>>
>> violII=\relative g {
>>   \repeat unfold 44 g4
>>   <g d'>2
>>   \repeat unfold 58 g4
>>   \bar "|."
>> }
>>
>> %% start with single Staffs, switch to divisi and back later
>> tstI = {
>>   \switchOff
>>   \repeat unfold 44 s4
>>   \switchOn
>>   s2
>>   \switchOff
>>   \repeat unfold 58 s4
>> }
>>
>> %% start with divisi, switch to single Staffs and back later
>> tstII = {
>>   \switchOn
>>   \repeat unfold 44 s4
>>   \switchOff
>>   s2
>>   \switchOn
>>   \repeat unfold 58 s4
>> }
>>
>> divisiVoiceI =
>>   \new Voice << \tstI \violII \violI >>
>>
>> divisiVoiceII =
>>   \new Voice << \tstII \violII \violI >>
>>
>> \score {
>>   \new StaffGroup \with { \consists "Keep_alive_together_engraver" }
>>   <<
>>     \new Staff \with { instrumentName = "Violin I"
>>                shortInstrumentName = "V I"
>>                \RemoveAllEmptyStaves
>>                \override VerticalAxisGroup.remove-layer = 2
>>              }
>>     \violI
>>     \new Staff \with { instrumentName = "Violin II"
>>                shortInstrumentName = "V II"
>>                \RemoveAllEmptyStaves
>>                \override VerticalAxisGroup.remove-layer = 2
>>              }
>>     \violII
>>     \new Staff \with { instrumentName = "Violins"
>>                shortInstrumentName = "V I&II"
>>                \override VerticalAxisGroup.remove-layer = 1
>>                \RemoveAllEmptyStaves
>>              }
>>     %% control divisi:
>>     %\divisiVoiceI
>>     \divisiVoiceII
>
> This is a total mess.  The point of remove-layers is that lower layer
> numbers override higher layer numbers, so your divisi control has to be
> applied to the lower layer number only, making the higher layer number
> appear as fallback when the lower layer number has no motivation to do
> so.
>
> But you switched around the layer numbering, making the divisi staves
> the _higher_ numbers (which only appear when the non-divisi staff
> suicides).  And then instead of applying the divisi controls to a
> selected group, you just apply it to everything, meaning that when you
> use "\switchOff", none of the contexts retain a reason to appear.
>
>>   >>
>>   \layout {
>>     short-indent = 2\cm
>>     indent = 3\cm
>>   }
>> }
>>
>> Am I doing something wrong?
>
> Definitely.  First start with the given example.  Then put your divisi
> controls _only_ in the divisi staff.  That's the one that is interested
> in forcing its appearance.
>
> If you really want to have the same source without tags, you could
> override DivisiStaff.keepAliveInterfaces and distribute context aliases
> in a manner where the overrides have no effect on the non-divisi staves
> without triggering errors.
>
> Separate DivisiStaff and whatever contexts (possibly just as containers
> with very few properties and engravers of themselves so that they can
> contain various Staff-like contexts) might help in layering the
> complexity.
>
> --
> David Kastrup

Hi David,

I'd wish to do the following.
Define the musical content for some instruments and probably a general
variable for breaks etc, p.e.

one = { e'1 f'4 g' a' f' g'1 }
two = { c'1 d'1 e' }
breaks = { s1 \break s1 \break s1 }

Then initiate a StaffGroup with staves for instrument `one` and `two`
and a Staff to combine both, p.e.

\new StaffGroup <<
  \new Staff = "single1"
    << \breaks \one >>
  \new Staff = "single2"
    << \breaks \two >>
  \new Staff = "divisi"
    << \new Voice { \voiceOne \one } \new Voice { \voiceTwo \two } >>
>>

Now I want to kill the "divisi"-Staff where I don't want it, thus I
intruduce a new Voice to be applied to the divisi-Staff.
The control-voice contains switchOn/Off-commands. (This is what I mean
above with "from inside".)
To get the killing happen the divisi-staff gets \RemoveAllEmptyStaves. I.e.:

switchOff = \set Staff.keepAliveInterfaces = #'()
switchOn = \unset Staff.keepAliveInterfaces

controlDivisi = { \switchOn s1 \switchOff s \switchOn s }

\new StaffGroup <<
  \new Staff = "single1" << \breaks \one >>
  \new Staff = "single2" << \breaks \two >>
  \new Staff = "divisi"
  \with {
    \RemoveAllEmptyStaves
  }
  <<
        \controlDivisi
        \new Voice { \voiceOne \one } \new Voice { \voiceTwo \two }
  >>
>>

The current situation is:
At the time the divisi-Staff is dead, the single-staves are alive and
being printed.
Ofcourse I now want the divisi-Staff to be dead where the
single-staves are alive.
So I put the "Keep_alive_together_engraver" into StaffGroup. And set
remove-layers.
Resulting in:

\new StaffGroup \with { \consists "Keep_alive_together_engraver" }
  <<
  \new Staff = "single1"
    \with {
      \override VerticalAxisGroup.remove-layer = 2
    }
    << \breaks \one >>
  \new Staff = "single2"
    \with {
      \override VerticalAxisGroup.remove-layer = 2
    }
    << \breaks \two >>
  \new Staff = "divisi"
    \with {
      \RemoveAllEmptyStaves
      \override VerticalAxisGroup.remove-layer = 1
    }
    <<
          \controlDivisi
          \new Voice { \voiceOne \one } \new Voice { \voiceTwo \two }
    >>
>>

And ...

it works, even if I change
controlDivisi = { \switchOff s1 \switchOn s \switchOff s }

???

Well, this whole post was meant to explain my thoughts while coding
the example from my previous mail.
I expected the code to fail like my previous.
It doesn't.
Though, even after your hints above, what's the essential difference?

I'll investigate.


Laters,
  Harm



reply via email to

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