[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
- Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/25
- Re: Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/25
- Re: Make a new staff occupy the same vertical space as a previous staff, David Kastrup, 2015/08/25
- Re: Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/25
- Re: Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/26
- Re: Make a new staff occupy the same vertical space as a previous staff, David Kastrup, 2015/08/27
- Re: Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/27
- Re: Make a new staff occupy the same vertical space as a previous staff, Simon Albrecht, 2015/08/27
- Re: Make a new staff occupy the same vertical space as a previous staff,
David Kastrup <=
- Re: Make a new staff occupy the same vertical space as a previous staff, Joel Ebel, 2015/08/29