Hello all,
Like many people on this list, I engrave a number of choral works using Lilypond. Like a smaller subset of those people, I engrave a number of large and very large works (musicals, operas, extended choral works, etc.), which require multiple editions (full score, pianovocal score, vocal book, etc.) each with their own font sizes, system and page breaks, and so on.
There are many times when two or more of my vocal or choral lines share material — for example, in my "Wither's Carol", the entire first verse (with the exception of a single two-measure chunk) is in "choral unison" (meaning everyone singing the same notes and words in their own usual octave) — whereas there are other very contrapuntal sections where material is totally independent. Hence, there are sections where a score COULD be adequately represented using only 1 choral staff, and other sections that require 2 or 3 or 4 (or even more) independent staves.
Ultimately, I would like to have Lilypond choose the correct number of staves so that horizontal and vertical spacing is optimal, using partcombine (or 'partexplode'?), cueing, etc., to accomplish its task.
I realize this is an AI nightmare and well outside Lilypond's current scope. So as a half-measure, I would love to be able to tag certain sections as "requires X staves", and then have Lilypond choose the least number of required staves based on system/line breaking. As I [manually] change the line breaks, the systems would automagically "expand" or "contract" as necessary/possible to accommodate the new layout. Unfortunately, the current tagging system is insufficient to do this, as far as I can tell.
Can anyone think of a reasonably easy way to implement this feature?
If so, I'll be happy to sponsor it.
Reasonably easy, no. Doable, yes. The easiest way in my mind's eye/ear would be for LilyPond to simultaneously (or sequentially if we're absolutely anti multi-threading) process different scores and then choose the best line breaks laterally across all of them, where a penalty for line breaking is (for example & amongst other things) the number of collisions between notes on a staff.
So, if there were n voices and voices could only be combined with adjacent voices (meaning never SB AT, for example), then you'd have 2^(n-1) possibilities of combinations, so 2^(n-1) scores to crunch starting from the end of parsing until the end of pre-processing.
This would take many, many hours to implement.
Cheers, MS |