The limits of StaffGroup nesting

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

The limits of StaffGroup nesting

Trevor Bača-2
Large orchestral scores sometimes nest StaffGroups fairly deeply. The
Rite of Spring has some stuff in the winds, with, for example, flutes
spread over four staves in the following way: piccolo getting its own
staff; 2 C flutes, each getting a staff and grouped together in a
staff group; alto flute in G getting its own staff; all three of those
staff groups grouped together in turn into a larger staff group; and
then maybe grouping into an even larger group or choir for the winds
as a whole. (Don't have the actual score in front of me at the office,
but you get the idea).

StaffGroups of StaffGroups seem to be limited 2-deep in Lily's current
implementation:

A StaffGroup containing an InnerStaffGroup renders the expected system
start brackets around the expected Staves:

======= Begin StaffGroup with InnerStaffGroup snippet ========

\new StaffGroup { <<

      \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
      \new InnerStaffGroup { <<
         \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
         \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
      >> }
      \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }

>> }

======= End StaffGroup with InnerStaffGroup snippet ========

The InnerStaffGroup system start bracket needs manual nudging to the
left, but both brackets are present around the expected staves.


Adding another InnerStaffGroup doesn't do what we might expect, however:

======= Begin StaffGroup with nested InnerStaffGroup snippet ========

\new StaffGroup { <<

      \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
      \new InnerStaffGroup { <<
         \new Staff { \repeat unfold 16 { d'4 d'4 d'4 d'4 } }
         \new InnerStaffGroup { <<
            \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
            \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }
         >> }
      >> }
      \new Staff { \repeat unfold 16 { c'4 c'4 c'4 c'4 } }

>> }

======= Begin StaffGroup with nested InnerStaffGroup snippet ========

The snippet just above should render three separate system start
brackets, with the innermost around staves 3 & 4 (counting from top to
bottom), the middle around staves 2, 3 & 4, and the outermost around
all five staves. Instead, the inner- and outermost brackets render
while the middle bracket doesn't.

I'm guessing that arbitrarily deep nesting of StaffGroups probably
hasn't made it to Lily yet but might be on the implementation list? Or
am I missing something and there is, in fact, a not-too-hacked way to
conjure up this sort of thing?

Han-Wen, if arbitrarily deep StaffGroup nesting isn't currently
possible would you consider adding it to the LSD sponsor page?



--
Trevor Bača
[hidden email]

_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Erik Sandberg
On Friday 11 November 2005 23.25, Trevor Bača wrote:
>
> The InnerStaffGroup system start bracket needs manual nudging to the
> left, but both brackets are present around the expected staves.
>
>
> Adding another InnerStaffGroup doesn't do what we might expect, however:

The type of a context can never be the same as the type of any of its
children.

If you want to increase the nesting arbitrarily, you'll probably have to
create new context types, using \layout { \context{...} } blocks. Look at
engraver-init.ly for ideas. If you nest in the right order, you can get
pretty deep nesting without tweaking, but it seldom makes sense:
\new StaffGroup <<
  \new ChoirStaff <<
    \new InnerStaffGroup <<
      \new PianoStaff <<
        ...
      >>
    >>
  >>
>>

--
Erik


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Han-Wen Nienhuys
In reply to this post by Trevor Bača-2
Trevor Bača wrote:

> Han-Wen, if arbitrarily deep StaffGroup nesting isn't currently
> possible would you consider adding it to the LSD sponsor page?

It would be neat to have arbitrary nesting, but it doesn't jibe well
with how contexts are created, as Erik also mentioned.

I'll have a think to see what I can do.


--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Han-Wen Nienhuys
Trevor Bača wrote:
> So, both for ease of implementation -- and because actual composers
> seem to bar and bracket things quite arbitrarily -- maybe the request
> shouldn't be for arbitrarily nested contexts, but instead to free up
> barring and bracketting as independent tasks from each other. Dunno,
> but something to think about when it comes time to add to the sponsor
> page.

Yes, this seems sensible. I think there would be a need for a

   systemStartDepth

property, setting the number of brackets a staff should be enclosed in,
and a

   nestedDelimiterType

property, setting the type of bracket for a certain nesting depth.

The nice thing is that we could completely drop the need for InnerXXX
contexts.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Trevor Bača-2
On 11/12/05, Han-Wen Nienhuys <[hidden email]> wrote:

> Trevor Bača wrote:
> > So, both for ease of implementation -- and because actual composers
> > seem to bar and bracket things quite arbitrarily -- maybe the request
> > shouldn't be for arbitrarily nested contexts, but instead to free up
> > barring and bracketting as independent tasks from each other. Dunno,
> > but something to think about when it comes time to add to the sponsor
> > page.
>
> Yes, this seems sensible. I think there would be a need for a
>
>    systemStartDepth
>
> property, setting the number of brackets a staff should be enclosed in,
> and a
>
>    nestedDelimiterType
>
> property, setting the type of bracket for a certain nesting depth.
>
> The nice thing is that we could completely drop the need for InnerXXX
> contexts.
Perfect, and thanks for the discussion. When the development schedule
permits, please email me and I'll be happy to sponsor.


--
Trevor Bača
[hidden email]

_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Erik Sandberg
> On 11/12/05, Han-Wen Nienhuys <[hidden email]> wrote:
> > Trevor Bača wrote:
> > > So, both for ease of implementation -- and because actual composers
> > > seem to bar and bracket things quite arbitrarily -- maybe the request
> > > shouldn't be for arbitrarily nested contexts, but instead to free up
> > > barring and bracketting as independent tasks from each other. Dunno,
> > > but something to think about when it comes time to add to the sponsor
> > > page.
> >
> > Yes, this seems sensible.

Does this mean that cycles will be allowed in the graph of context
definitions?

--
Erik


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Han-Wen Nienhuys
Erik Sandberg wrote:

>>On 11/12/05, Han-Wen Nienhuys <[hidden email]> wrote:
>>
>>>Trevor Bača wrote:
>>>
>>>>So, both for ease of implementation -- and because actual composers
>>>>seem to bar and bracket things quite arbitrarily -- maybe the request
>>>>shouldn't be for arbitrarily nested contexts, but instead to free up
>>>>barring and bracketting as independent tasks from each other. Dunno,
>>>>but something to think about when it comes time to add to the sponsor
>>>>page.
>>>
>>>Yes, this seems sensible.
>
>
> Does this mean that cycles will be allowed in the graph of context
> definitions?

No, it means that we don't mirror bracket nesting in context nesting.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Erik Sandberg
On Monday 14 November 2005 02.10, Han-Wen Nienhuys wrote:

> Erik Sandberg wrote:
> >>On 11/12/05, Han-Wen Nienhuys <[hidden email]> wrote:
> >>>Trevor Bača wrote:
> >>>>So, both for ease of implementation -- and because actual composers
> >>>>seem to bar and bracket things quite arbitrarily -- maybe the request
> >>>>shouldn't be for arbitrarily nested contexts, but instead to free up
> >>>>barring and bracketting as independent tasks from each other. Dunno,
> >>>>but something to think about when it comes time to add to the sponsor
> >>>>page.
> >>>
> >>>Yes, this seems sensible.
> >
> > Does this mean that cycles will be allowed in the graph of context
> > definitions?
>
> No, it means that we don't mirror bracket nesting in context nesting.

Then, how does this make it possible to drop InnerXX contexts? There must
still be one individual StaffGroup-ish context definition for each level of
context nesting?

Currenntly, the following trick can be applied to achieve arbitrarily deep
nesting. In what way will this be simplified?

\score {
\new OuterStaffGroup <<
\new StaffGroup <<
 \new InnerStaffGroup << \new Staff c1 \new Staff c1 >>
 \new Staff c1
>>
 \new Staff c1
>>

\layout {
\context {
  \StaffGroup
  \name OuterStaffGroup
  \accepts "StaffGroup"
}
\context {\Score \accepts "OuterStaffGroup" }
}
}

--
Erik


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: The limits of StaffGroup nesting

Han-Wen Nienhuys
Erik Sandberg wrote:

> Then, how does this make it possible to drop InnerXX contexts? There must
> still be one individual StaffGroup-ish context definition for each level of
> context nesting?
>

What's the point in context nesting, except for being able to nest brackets?

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user