Re: Make a new staff occupy the same vertical space as a previous staff

[Joel Ebel]

Thanks for all the help. As per Simon's advice, I'm now doing this to
get rid of the TAB clef on the first line of RhythmicStaff, and I like
the removal of the DevNull. It's perhaps a toss-up whether the source
is easier to read with << >> around the TabStaff it vs putting a
\stopStaff after it, but perhaps internally it is cleaner this way.
The result of this is now just what I want.

\version "2.19.25"

\new Line {
  <<
    {
      <<
        \new TabStaff {
          \relative c {c1}
          \omit TabStaff.Clef
        }
      >>
      \break
      \new RhythmicStaff \relative c' { 1 \break 1 }
    }
  >>
}

\layout {
  \context {
    \name "Line"
    \type "Engraver_group"
    \consists "Axis_group_engraver"
    \accepts TabStaff
    \accepts RhythmicStaff
  }
  \context {
    \Score
    \accepts "Line"
  }
}

On Fri, Aug 28, 2015 at 11:48 AM, David Kastrup <address@hidden> wrote:
> Joel Ebel <address@hidden> writes:
>
>> On Thu, Aug 27, 2015 at 2:53 AM, David Kastrup <address@hidden> wrote:
>>> Oh wow.  This one is seriously annoying.  If you take out all
>>> \stopStaff, it is apparent that the TabStaff is alive through the whole
>>> piece.  This is also the case when replacing \new Line with \new
>>> StaffGroup.  This is something like the "the first new context in a
>>> group is kept alive" rule.  If you replace
>>>
>>>     \new TabStaff ...
>>>
>>> with
>>>
>>>     << \new DevNull {} \new TabStaff ... >>
>>>
>>> the problem goes away even without \stopStaff.  But that's seriously
>>> messed up.
>>>
>>> --
>>> David Kastrup
>>
>> That's abstract, but the result is much better.
>
> It's also snake oil.  It turns out that all that is required is writing
>
> << \new TabStaff ... >>
>
> The reason is that context descents in { ... } are "sticky": when
> writing something like
>
> {
>   \override Voice.x = y
>   \override Voice.z = u
>   ...
> }
>
> this is represented somewhat like
>
> {
>   \context Voice \pushProperty x y
>   \context Voice \pushProperty z u
>   ...
> }
>
> and when started at top level, not every line should start a new
> Voice/Staff of its own.
>
> This stickiness is not prevalent with <<...>>: every element in <<...>>
> maintains its own context without affecting the outer context.  So
> adding a <<...>> wrapper around an element saves its context descents
> from being sticky.  For example,
>
>
>
> creates three staves (\time 3/4 does not actually get a staff of its
> own, but since it does not get called within a staff, none of the 3 time
> signatures have point-and-click back to the source file).
>
>
>> The one remaining issue is that if the switch to RhythmicStaff occurs
>> on a line break, TAB is still printed on the first subsequent line. I
>> can live with it, but is it possible to prevent that? Simple example
>> below. TAB is on line 2, but not line 3.
>
> So this gets us
>
>> \version "2.19.25"
>>
>> \new Line {
>>   <<
>>     \new TabStaff { \relative c { c1 } }
>>   >>
>>   \break
>>   \new RhythmicStaff { 1 \break 1 }
>> }
>>
>> \layout {
>>   \context {
>>     \name "Line"
>>     \type "Engraver_group"
>>     \consists "Axis_group_engraver"
>>     \accepts TabStaff
>>     \accepts RhythmicStaff
>>   }
>>   \context {
>>     \Score
>>     \accepts "Line"
>>   }
>> }
>
> Which again shows the TAB clef.  I consider this a bug.  One can
> probably fiddle with break invisibilities in order to get this under
> control while the bug isn't fixed.
>
> --
> David Kastrup
>