On 14 déc. 2012, at 14:47, Kieren MacMillan <kieren_macmil...@sympatico.ca>
wrote:
> 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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
