parts sharing a staff

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

parts sharing a staff

Shevek
I often run into situations where two parts share a staff some of the time and have individual staffs the rest of the time. The way I handle it is like this (including only relevant details):

\new StaffGroup \with {
  instrumentName = "Flute  "
  shortInstrumentName = "Fl."
} <<
  \new Staff = "Fl1" \with {
    instrumentName = \markup\column { "1" "2" }
    shortInstrumentName = \markup\column { "1" "2" }
  } << \global \partcombine \fluteI \fluteII >>
  \new Staff = "Fl2" \with {
    instrumentName = \markup\column { "1" "2" }
    shortInstrumentName = \markup\column { "1" "2" }
    \override VerticalAxisGroup.remove-empty = ##t
    \override VerticalAxisGroup.remove-first = ##t
  } << \global >>
>>
   
fluteI {
  \tag #'score {
    \partcombineApart
    \oneVoice
  }
  % music....
}
   
fluteII = {
  \tag #'score {
    \change Staff = "Fl2"
    \oneVoice
  }
  % music....
}

I use \partcombineApart with the second part \change'd to the second staff as the default setting, and use \partcombineChords or \partcombineUnisono when appropriate, since those pull the second part into the top staff without needing to write \change Staff.

First, I thought this might just be of interest to others who deal with a similar scenario. Are you using a similar technique, or do you have a better approach?

Second, this strategy leads to the necessity of manually writing \set Staff.shortInstrumentName = "1" whenever the second staff is visible, and back again to \column { "1" "2" } whenever the second staff is hidden. Since that depends on system breaking, which changes as I compose, getting the correct labels in the left margin is a continual source of tedious manual bugfixing.

What I'd really like is to be able to write some function or engraver that checks whether the second staff is visible or hidden on that system, and changes the shortInstrumentName on the top staff back and forth accordingly. How feasible would such a project be? If it is feasible, how could I begin to approach it?
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Kieren MacMillan
Hi Shevek,

> I often run into situations where two parts share a staff some
> of the time and have individual staffs the rest of the time.

This is quite common. (I have scores where up to 8 different parts will share between 1 and 8 staves, depending on the situation.)

> The way I handle it is like this [...]
> I thought this might just be of interest to others who deal with a similar scenario.

That's very interesting! Right now I'm putting together a comparative analysis of the different methods of coding shared/split staves; this is not one I had previously seen or considered. As it relies on the partcombiner — which is both feature-poor and limited to two voices — it has some drawbacks; but there are also some benefits to the approach. Thanks for sharing it!

> Are you using a similar technique, or do you have a better approach?

"Better" is a matter of opinion… I know of three other primary ways of approaching it — each has its pros and cons.

> Second, this strategy leads to the necessity of manually writing \set
> Staff.shortInstrumentName = "1" whenever the second staff is visible, and
> back again to \column { "1" "2" } whenever the second staff is hidden. Since
> that depends on system breaking, which changes as I compose, getting the
> correct labels in the left margin is a continual source of tedious manual bugfixing.

1. Other mechanisms would allow you to set the instrument name once and never adjust it. (But the tradeoffs might not be worth that modest gain.)

2. Speaking from a depth of experience, I might recommend not worrying about margin labels while composing… I find the mode-switching keeps me from harnessing really good composition focus/flow.

> What I'd really like is to be able to write some function or engraver that […]

Well, that is a separate — and very compelling — kettle of fish. For quite some time, I've been thinking about (and asking/posting about, and offering to sponsor, etc.) a staff-labelling engraver which would determine the name of the performer(s) who were represented by that staff, using the partcombiner or not.

> How feasible would such a project be?

I don't see why it couldn't be done fairly easily using a Scheme engraver.

> If it is feasible, how could I begin to approach it?

That's a different story… My Scheme-fu is weak (though I'm working my way through some of the learning curve right now). Hopefully someone else can help.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Shevek
Kieren MacMillan wrote
That's very interesting! Right now I'm putting together a comparative analysis of the different methods of coding shared/split staves; this is not one I had previously seen or considered. As it relies on the partcombiner — which is both feature-poor and limited to two voices — it has some drawbacks; but there are also some benefits to the approach. Thanks for sharing it!
I'd be fascinated to have an in depth conversation about shared staves in Lilypond. I've been giving a fair bit of thought to how I'd like it to work, at least based on my particular use case.

Kieren MacMillan wrote
2. Speaking from a depth of experience, I might recommend not worrying about margin labels while composing… I find the mode-switching keeps me from harnessing really good composition focus/flow.
Agreed. It's not something I fix constantly, but it's annoying to worry about every time I want to print a fair copy of a draft, e.g. to submit to something.
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Kieren MacMillan
Hi Shevek,

> I'd be fascinated to have an in depth conversation about shared staves in
> Lilypond. I've been giving a fair bit of thought to how I'd like it to work,
> at least based on my particular use case.

I'd like that, too!

I’ve found that the whole situation is fairly simple if the layout is fixed (e.g., when I'm copying an existing edition exactly), and it becomes *massively* more complex when I want options/flexibility in my layout choices. For example, in the short choral piece I'm currently engraving (SATB + brass sextet), there are sections which are *optimally* engraved in every possible configuration:
  1 staff: SATB unison
  2 staves: SA+TB (a cappella chorus); 3 high brass + 3 low brass (instrumental interlude, in reduction); etc.
  3 staves: SATB unison + 3 high brass + 3 low brass;
  4 staves: S+A+T+B (a cappella); SA+TB + 3 high brass + 3 low brass; etc.
  ...
  10 staves: S + A + T + B + 1 staff per brass part.

In terms of outputs, I want to have at least the following:
  octavo choral score (with brass as a 2-stave reduction)
  U.S. letter choral score (with brass as a 2-stave reduction)
  A4 choral score (with brass as a 2-stave reduction)
  9x12 full score (with brass 'correctly engraved')

I would like to be able to test a large number of layout possibilities as efficiently as possible. In a perfect world, I want to be able to play around with system (line) breaks and see all the 'good' casting-off choices without having to do much work beyond just choosing where the breaks are: staff names, staff combining and splitting, lyric attachment/affinity, etc. should all just Do The Right Thing™.

Some things are already relatively easy to either automate, or at least get done with pretty minimal effort. I've defined some syntactic sugar (\letStaffVanish, \showStaff, etc.) so that *if* a certain measure requires 4 full choral staves, they will appear as desired. Mark Knoop (who did most of the really great keep-alive-together programming in the last few years) also created some amazing sugar, which helps Lily *always* choose the most efficient layout. But most of these things require a *lot* of engineering in the score file, and the staff code quickly gets quite large and complex.

Also, it would be best if layout and other presentation decisions could be kept out of the content (music) code. I like to use the edition-engraver to implement almost all of the choices (line and page breaks, staff naming, etc.). Hence, for example, adding \partcombineApart into the music code isn't necessarily the best option from a reuse perspective. That being said, sometimes I feel like my whole engraving life is a series of solutions in search of a problem…  =\

Perhaps the best plan is for us to start with some *very simple* use cases — more simple than the choral work I mention above (and which Mark K "solved") — and discuss how existing Lilypond features do or do not satisfy the constraints/expectations. And once we've set up some basic test files/cases, we should definitely get Mark K and David K [at least] in on the thread, because they have (I believe) the most in-depth knowledge of how all of the remove-layer stuff does/can work.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Shevek
I don't mind having to insert the occasional layout-related command — I actually prefer the ability to switch between clearly defined behaviors, rather than have Lilypond try to guess which to use. (IMO, the fact that the Automatic mode exists is the biggest design philosophy problem with partcombiner.) The biggest problem caused by inserting commands mid-music is that it breaks up multi-measure rests for the parts, but I wrote a snippet a few years ago that stitches the multi-measure rests back together.

Correct me if I'm misunderstanding, but it sounds like you're using the edition engraver to do various score layouts, but in each version the staff distribution will stay the same throughout the piece. My use case is a bit different, as within the course of a piece I need to be able to condense orchestral winds into shared staves and split them up again, depending on the musical context. I don't see how it would be possible to do that without inserting layout commands into the music code.

From my perspective, the annoyance is that there are several separate engraving issues that depend upon one another and upon system breaking:

1) Which parts are on which staff when, and whether they are unison, chords, or voices? In particular, when switching from unison or chords to separate staves, if the same-staff passage continues over a system break it should automatically split into separate staves wherever the break happens to occur. The command to go to separate staves should appear just before the passage to which it applies.

2) The staff naming depends on the status of the divisi and the system breaking, as we alluded to earlier.

3) Some text markups change depending on whether staves are combined. For instance, it should read "solo" or "1. solo" depending on whether the player needs to be specified. Also, "a2" should automatically be reprinted after measures of rest.

The most critical thing for me is being able to do score and parts from the same music, so that I can revise and compose cleanly.
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Vaughan McAlley
In reply to this post by Kieren MacMillan
On 16 June 2017 at 13:05, Kieren MacMillan <[hidden email]> wrote:

Perhaps the best plan is for us to start with some *very simple* use cases — more simple than the choral work I mention above (and which Mark K "solved") — and discuss how existing Lilypond features do or do not satisfy the constraints/expectations. And once we've set up some basic test files/cases, we should definitely get Mark K and David K [at least] in on the thread, because they have (I believe) the most in-depth knowledge of how all of the remove-layer stuff does/can work.

It would not be too hard to automate running Lilypond with one's scripting language of choice. One thing I do is see the largest I can make a score while it still fits on to x pages, by compiling a score at ever more specific sizes.

If there was engraver/listener that outputs to a separate file where line and page breaks eventually occur, you could re-run Lilypond adding a file that adds these breaks explicitly and whatever other information you need (in my case it would be a VS indication if and only if a page-break occurs a particular point).

This would be quite a bit more complicated, but with a listener from keepAliveInterfaces you could theoretically add instrument and group names as needed throughout the score.

(Maybe these listeners already exist...)

Vaughan


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

Re: parts sharing a staff

Kieren MacMillan
In reply to this post by Shevek
Hi Shevek,

> I don't mind having to insert the occasional layout-related command —
> I actually prefer the ability to switch between clearly defined behaviors,
> rather than have Lilypond try to guess which to use.

I like having both options.  =)

> The biggest problem caused by inserting commands mid-music is
> that it breaks up multi-measure rests for the parts

That's definitely a problem. I also just prefer separating presentation from content as much as possible — putting (e.g.) \partcombineChords right in fluteII is great when I'm combining fluteI & fluteII, but maybe doesn't make sense if I'm combining fluteII & fluteIV in some other edition/score, etc.

> Correct me if I'm misunderstanding, but it sounds like you're using the
> edition engraver to do various score layouts, but in each version the staff
> distribution will stay the same throughout the piece.

No — the staff distribution changes.

> My use case is a bit different, as within the course of a piece
> I need to be able to condense orchestral winds into shared staves
> and split them up again, depending on the musical context.

Yes, I do that.

> I don't see how it would be possible to do that without
> inserting layout commands into the music code.

The edition-engraver can "inject" the layout commands into the score at the correct moment. For example, I use the e-e to put a \showMMRs command into a frenched score where I want to force an empty staff to appear (where it otherwise wouldn't).

> 1) Which parts are on which staff when, and whether they are unison, chords,
> or voices? In particular, when switching from unison or chords to separate
> staves, if the same-staff passage continues over a system break it should
> automatically split into separate staves wherever the break happens to
> occur. The command to go to separate staves should appear just before the
> passage to which it applies.
>
> 2) The staff naming depends on the status of the divisi and the system
> breaking, as we alluded to earlier.
>
> 3) Some text markups change depending on whether staves are combined. For
> instance, it should read "solo" or "1. solo" depending on whether the player
> needs to be specified. Also, "a2" should automatically be reprinted after
> measures of rest.
>
> The most critical thing for me is being able to do score and parts from the
> same music, so that I can revise and compose cleanly.

I agree with all of this. Being able to do score and parts from the same music is yet another reason I always want to keep the music code clear of any presentation-layer commands.

I'll put together a small example of how I use the edition-engraver to inject presentation commands into a score. Until you see it in action, I imagine it would be hard to understand what I'm talking about (and the power of that ability).

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Kieren MacMillan
Hi Shevek,

>> I don't mind having to insert the occasional layout-related command —
>> I actually prefer the ability to switch between clearly defined behaviors,
>> rather than have Lilypond try to guess which to use.
>
> I like having both options.  =)

For example, just because we have the commands \break and \pageBreak (a.k.a. "clearly defined behaviours") at our disposal, should we always turn off Lilypond's auto-breaking options (a.k.a. *not* "have Liypond try to guess which to use")?

Best,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Kieren MacMillan
In reply to this post by Shevek
Hi Shevek,

> Correct me if I'm misunderstanding, but it sounds like you're using the
> edition engraver to do various score layouts, but in each version the staff
> distribution will stay the same throughout the piece. My use case is a bit
> different, as within the course of a piece I need to be able to condense
> orchestral winds into shared staves and split them up again, depending on
> the musical context. I don't see how it would be possible to do that without
> inserting layout commands into the music code.

Attached is a silly example showing one way of having separated and condensed wind staves appear and disappear at will, without inserting layout commands into the music (content) code — instead, all layout choices are made "at runtime" (i.e., in the presentation layer), using the edition-engraver. Note that the staff names appear correctly, "automagically".

As I indicated earlier in this thread, there are pros and cons to this method. But I hope this clears that part of it up for you.

Best,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]

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

twoflutes.ly (3K) Download Attachment
twoflutes.pdf (59K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Shevek
Okay, I see what you're doing. I can see how this would be helpful if you're an engraver doing multiple editions of a piece. From my perspective, this type of separation of concerns is actually counterproductive, because as I compose I may add or subtract measures many times. Having to keep the editorial changes synced with the score would mean I'm in effect defining the music twice, and it would be less readable, because it obscures the musical reason for combining or separating staves.
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Shevek
In reply to this post by Kieren MacMillan
> Being able to do score and parts from the same music is yet another reason I always want to keep the music code clear of any presentation-layer commands.

I just make sure to precede every partcombine instruction with a \tag for the score it pertains to.

>> The biggest problem caused by inserting commands mid-music is
>> that it breaks up multi-measure rests for the parts

>That's definitely a problem.

Here's my snippet to recombine broken MultiMeasureRests: rest-combiner.ly
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Kieren MacMillan
In reply to this post by Shevek
Hi Shevek,

> as I compose I may add or subtract measures many times.
> Having to keep the editorial changes synced with the score

Currently that *is* an issue. (Note: I don't compose into Lilypond; I tried it a few times, but found it *way* too frustrating!) Fortunately, the problem will be greatly reduced (possibly even eliminated?) in the near future, when the edition-engraver supports id- and anchor-based mods.

> it would be less readable, because it obscures the
> musical reason for combining or separating staves.

Not sure I understand your meaning…?
What is an example of a musical reason, *not* part of the presentation layer, for combining/separating staves?

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Kieren MacMillan
In reply to this post by Shevek
Hi Shevek,

> I just make sure to precede every partcombine instruction with a \tag for the score it pertains to.

I used to use the \tag mechanism a lot, before I discovered the edition-engraver.
Now I almost never use them — I find they clutter up my content code.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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

Re: parts sharing a staff

Shevek
In reply to this post by Kieren MacMillan
Kieren MacMillan wrote
> it would be less readable, because it obscures the
> musical reason for combining or separating staves.

Not sure I understand your meaning…?
What is an example of a musical reason, *not* part of the presentation layer, for combining/separating staves?
Well, it is part of the presentation layer, but the specific decision of how to combine parts in a particular passage depends on what the music is. If I decide one to day to change a unison passage to octaves, then the next to make it solo, and after that to make it dovetail contrapuntally, those musical content changes all directly affect how the parts should be combined on a staff or not. Abstracting the decision to combine or not would mean I need to look in two places in the code to understand what's happening there.

I see it as similar to modifying the shape of a slur. It's purely presentational, but it depends directly on the musical content, so I would find it rather confusing to put the override in a separate part of the code from the notes.
Reply | Threaded
Open this post in threaded view
|

Re: parts sharing a staff

Kieren MacMillan
Hi Shevek,

> Well, it is part of the presentation layer, but the specific decision of how
> to combine parts in a particular passage depends on what the music is. If I
> decide one to day to change a unison passage to octaves, then the next to
> make it solo, and after that to make it dovetail contrapuntally, those
> musical content changes all directly affect how the parts should be combined
> on a staff or not. Abstracting the decision to combine or not would mean I
> need to look in two places in the code to understand what's happening there.
>
> I see it as similar to modifying the shape of a slur. It's purely
> presentational, but it depends directly on the musical content, so I would
> find it rather confusing to put the override in a separate part of the code
> from the notes.

Ah, I understand.

Yes, different ways of working with Lilypond definitely work more or less well depending on which hat I'm wearing at a given time (composer, arranger, orchestrator, or engraver). That's why I try, if at all possible, to avoid even cracking Lilypond open until I'm converging on the final engraving: at that point, I can enter all the musical content (notes, dynamics, curves, text, etc.) at a single go, and then turn my attention entirely to the presentation layer (which lives in a single, but separate, part of the file-set). On the rare occasion I need to bounce back and fix something in the content code, Frescobaldi's shortcuts make it dead simple to do so.

Anyway, thanks for letting me know about your combining/splitting process/mechanism — it will be a useful addition to the document I'm putting together.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


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