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: i...@kierenmacmillan.info _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
