Splitting Staves

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

Splitting Staves

Valentin Petzel
Hello,

As it is I think one of the important features missing in Lilypond is the
ability to split one staff into multiple staves, which is a feature quite
nescessary for orchestral and choral settings. There is an ”official“ hack to do
it by using different staves and switching context, but this is neighter
beautyful nor useful in large settings and it bears the problem that one needs
to manually specify all these splits, including System breaks &c.

So what I want to work on is some sort of ”Splittable Staff“. Main specs should
be:

→ At any point in the Score a staff should be splittable
→ Splits can be denoted by a markup like divisi
→ If a split occurs within on system, one should have the choice between:
→→ Extending the split to the whole system, doubling not split notes (as it’s
usually done)
→→ Splitting the staff in the middle of the system, as sometimes done in more
complex scores.
→ There should be a penalty for having a longer split start or end in such a
way, that it eighter starts very late into the system or ends very early in
the system (leading to lots of duplicated stuff)
→ One should be able to specify brackets for splits
→ One should be able to specify if a split will occur only at a barline
(potentially doubling stuff) of at any point
→ There should be a way to make Voices work nicely with splits (so if you
split four Voices 1,2,3,4 from high to low into 1,2 and 3,4 they should
automatically be remapped to the voice configurations 1,3,4,2 when together,
and 1,2 and 1,2 when split.
→ It should be possible to do nested splits
→ It should be possible to specify Instrument names for split Staves

I have thought up a way one could specify this, but I do not have time to
elaborate it here, so I will probably follow up on this.

Now, for the gist of my question: I’m very well versed with the Lilypond
codebase, so I appreciate if someone could give me a few directions, what
parts I should study to get into the right direction.

Best regards,
Valentin

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

David Kastrup
Valentin Petzel <[hidden email]> writes:

> Hello,
>
> As it is I think one of the important features missing in Lilypond is the
> ability to split one staff into multiple staves, which is a feature quite
> nescessary for orchestral and choral settings. There is an ”official“ hack to do
> it by using different staves and switching context, but this is neighter
> beautyful nor useful in large settings and it bears the problem that one needs
> to manually specify all these splits, including System breaks &c.

Take a look at input/regression/divisi-staves.ly : that at least
showcases some low-level interfaces/hooks for implementing that sort of
functionality.  It doesn't really constitute a user interface, though.

> So what I want to work on is some sort of ”Splittable Staff“. Main specs should
> be:
>
> → At any point in the Score a staff should be splittable
> → Splits can be denoted by a markup like divisi
> → If a split occurs within on system, one should have the choice between:
> →→ Extending the split to the whole system, doubling not split notes (as it’s
> usually done)
> →→ Splitting the staff in the middle of the system, as sometimes done in more
> complex scores.
> → There should be a penalty for having a longer split start or end in such a
> way, that it eighter starts very late into the system or ends very early in
> the system (leading to lots of duplicated stuff)
> → One should be able to specify brackets for splits
> → One should be able to specify if a split will occur only at a barline
> (potentially doubling stuff) of at any point
> → There should be a way to make Voices work nicely with splits (so if you
> split four Voices 1,2,3,4 from high to low into 1,2 and 3,4 they should
> automatically be remapped to the voice configurations 1,3,4,2 when together,
> and 1,2 and 1,2 when split.
> → It should be possible to do nested splits
> → It should be possible to specify Instrument names for split Staves
>
> I have thought up a way one could specify this, but I do not have time to
> elaborate it here, so I will probably follow up on this.
>
> Now, for the gist of my question: I’m very well versed with the Lilypond
> codebase, so I appreciate if someone could give me a few directions, what
> parts I should study to get into the right direction.

See above for some low-level hooks, but the rest will be a bunch of
programming work including juggling contexts and both split and
condensed versions typeset in parallel.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

Kieren MacMillan
In reply to this post by Valentin Petzel
Hi Valentin,

> As it is I think one of the important features missing in Lilypond is the
> ability to split one staff into multiple staves, which is a feature quite
> nescessary for orchestral and choral settings.

The term "missing" is perhaps misleading: I do exactly this all the time. That being said, I agree with the basic idea here, i.e., that the mechanisms need to be codified, improved, and properly documented in order to make this "feature" (really, a large collection of disparate features working together for a single purpose) excellent.

> There is an ”official“ hack to do it by using different staves and switching context,
> but this is neighter beautyful nor useful in large settings and it bears the problem
> that one needs  to manually specify all these splits, including System breaks &c.

One correction: you don’t need to manually specify system breaks, if you code the divisi staves properly.

> So what I want to work on is some sort of ”Splittable Staff“.

I love the concept… but I‘m dubious that it can be done fully and correctly without a proper and reliable partcombiner as well.

> → At any point in the Score a staff should be splittable
> → Splits can be denoted by a markup like divisi
> → If a split occurs within on system, one should have the choice between:
> →→ Extending the split to the whole system, doubling not split notes (as it’s
> usually done)
> →→ Splitting the staff in the middle of the system, as sometimes done in more
> complex scores.
> → There should be a penalty for having a longer split start or end in such a
> way, that it eighter starts very late into the system or ends very early in
> the system (leading to lots of duplicated stuff)
> → One should be able to specify brackets for splits
> → One should be able to specify if a split will occur only at a barline
> (potentially doubling stuff) of at any point
> → There should be a way to make Voices work nicely with splits (so if you
> split four Voices 1,2,3,4 from high to low into 1,2 and 3,4 they should
> automatically be remapped to the voice configurations 1,3,4,2 when together,
> and 1,2 and 1,2 when split.
> → It should be possible to do nested splits
> → It should be possible to specify Instrument names for split Staves

All admirable goals!

> Now, for the gist of my question: I’m very well versed with the Lilypond
> codebase, so I appreciate if someone could give me a few directions, what
> parts I should study to get into the right direction.

Look into "divisi staves", "partcombiner", and similar.

I would love to help you work on this, if you’re interested in collaboration. As you look through the archives, I’m sure you’ll see that I’ve been working on this problem for at least a decade.  ;)

Best,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

Dan Eble
On Feb 6, 2020, at 09:32, Kieren MacMillan <[hidden email]> wrote:
>
>> So what I want to work on is some sort of ”Splittable Staff“.

This terminology looks at the use case from a point of view that might not be very consistent with LilyPond.  Let's think carefully about what we want to call this, because names have a way of coloring the problem-solving process.

LilyPond already has some features that can move a voice between staves (\change and \autoChange), and is able to hide staves without music.  We should entertain "moving voices" as an alternative idea to "splitting staves" so that we are more likely to find the best solution.  Maybe there are more ways of looking at it that we should also consider.

(I don't mean for that to sound the slightest bit discouraging.  I think it's great that this is being discussed.)

> I love the concept… but I‘m dubious that it can be done fully and correctly without a proper and reliable partcombiner as well.

+1, however something less than "fully and correctly" might work for a good number of people and be implemented sooner.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

Kieren MacMillan
Hi Dan (et al.),

> On Feb 6, 2020, at 09:32, Kieren MacMillan <[hidden email]> wrote:
>> So what I want to work on is some sort of ”Splittable Staff“.

Just to be clear, Valentin wrote that, not me.  =)

> This terminology looks at the use case from a point of view that might not be very consistent with LilyPond.  Let's think carefully about what we want to call this, because names have a way of coloring the problem-solving process.

Agreed.

> We should entertain "moving voices" as an alternative idea to "splitting staves" so that we are more likely to find the best solution.

Definitely. In the best case scenario, I’ve always dreamed that we could move items not just to adjacent staves (as would be true in a standard divisi situation), but also to adjacent non-staves [!] and non-adjacent contexts of all types (staves and non-staves). I look forward to discussing the possibilities.

> +1, however something less than "fully and correctly" might work for a good number of people and be implemented sooner.

Oh, I’m definitely of the "progress not perfection" mindset… but I also believe (and think you agree) that we should try to get the best possible fundamentals/plan in place, so that we (a) have a good foundation to build on and add to in the future, and (b) don’t have to reinvent the wheel "the next time".

Best,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

David Kastrup
Kieren MacMillan <[hidden email]> writes:

> Hi Dan (et al.),
>
>> On Feb 6, 2020, at 09:32, Kieren MacMillan <[hidden email]> wrote:
>>> So what I want to work on is some sort of ”Splittable Staff“.
>
> Just to be clear, Valentin wrote that, not me.  =)
>
>> This terminology looks at the use case from a point of view that
>> might not be very consistent with LilyPond.  Let's think carefully
>> about what we want to call this, because names have a way of
>> coloring the problem-solving process.
>
> Agreed.

Without having even looked at the problem, let me add that the
programming/Scheme layer of LilyPond often allows to _map_ a problem
description in composer terms to an approach in LilyPond terms.  So
sometimes finding a consistent way of describing and structuring a
problem may garner the necessary help from the list that then provides a
solution that talks to the user in composer terms, and to the program in
LilyPond terms.

End of pontification.  Just something that tends to lurk in the back of
my mind and sometimes might give a different outlook on a problem.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Staves

Kieren MacMillan
Hi David,

> the programming/Scheme layer of LilyPond often allows to _map_
> a problem description in composer terms to an approach in LilyPond terms.
> So sometimes finding a consistent way of describing and structuring a
> problem may garner the necessary help from the list that then provides a
> solution that talks to the user in composer terms, and to the program in
> LilyPond terms.

An excellent point. I’ll think about the problem from a composer’s and engraver’s standpoint (where I spend most of my working hours) as well as from a programmer’s standpoint (where I only spend a minority of my working hours) and see what similarities and differences emerge; hopefully that reflection will help when it comes time to discuss possible maps.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]