lilypond-user
[Top][All Lists]
Advanced

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

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


From: David Kastrup
Subject: Re: Make a new staff occupy the same vertical space as a previous staff
Date: Fri, 28 Aug 2015 17:48:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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,

{
  <<\clef bass>>
  <<\key d \major>>
  <<\time 3/4>>
  c4 d e
}
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

reply via email to

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