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 <d...@gnu.org> wrote:
> Joel Ebel <jbe...@mybox.org> writes:
>
>> On Thu, Aug 27, 2015 at 2:53 AM, David Kastrup <d...@gnu.org> 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
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
