Re: Survey: Large scores

[Urs Liska]

Am 17.04.2015 um 20:44 schrieb H. S. Teoh:
> On Fri, Apr 17, 2015 at 10:51:41AM +0200, Orm Finnendahl wrote:
> [...]
> > The only really painful part was the partcombiner which seems very
> > buggy, but was indispensable as I needed to save as much vertical
> > space as possible.
>
> Yeah, I've run into quite a number of \partcombine myself.

Yes, me too. From our huge project only the cue notes are still missing 
(apart from maybe some finishing touches) as the last major new 
technique. And I have to say the combination of voices is the _only_ 
thing where I ran into trouble with LilyPond.

> Most of it
> was caused by unusual input, though -- meaning one voice ended
> prematurely and \partcombine doesn't seem to know to mark the remainder
> of the other voice as "Solo" or "Solo II". Filling out both voices so
> that they end at the same time got rid of most of this category of bugs.
>
> More annoying is the fact that \partcombine often gets confused when the
> two voices have very divergent rhythms -- crescendo hairpins don't
> merge, dynamics get printed twice,

I have recently written an engraver that removes duplicate markups, 
dynamics and line spanners. Seems to work quite reliably (you may look 
for a thread about "duplicate items" or something like this, from last 
week or so).

> short rests in the voices cause silly
> "a2" and "Solo" markings several times per bar within 1-2 notes of each
> other, etc.. I've had some luck in ironing out most of these issues with
> manually-placed \partcombineApart, \partcombineChords, and
> \partcombineAutomatic, etc.,

I found this approach very tedious - and obscure. Because when you 
encounter an issue in the output of a longer combined voice it's 
absolutely not obvious in which mode the partcombiner is at the moment, 
not even if there is a manual setting active right now or if the current 
state is determined automatically by the partcombiner.

> but there are still a few cases where I had
> to use \override DynamicText.stencil and \override Hairpin.stencil to
> hide the redundant marks. Most annoyingly, since I use the same source
> for generating the instrument parts, where the marks should *not* be
> hidden, I ended up writing macros that use \tag to hide certain marks
> only inside \partcombine but to leave them intact elsewhere.

I did not go that far, but I definitely think it should not be necessary 
to do such awkward workarounds for such a default (I don't say trivial) 
task.

> The one thing that I currently have not been able to solve is how to
> make ScoreMarks contexts die when an associated Staff or StaffGroup has
> hara-kiri'd.
> ...

I can't comment on that.
But the most annoying limitation of the partcombiner is actually a 
result of a limitation in LilyPond: the fact that spanners are voice-bound.
That means that when a slur starts at a \partcombineApart section it 
can't be ended in a \partcombineChords section. This often requires 
extremely ugly workarounds, and in not too few cases it even required me 
to change the output to something I wouldn't want to do, just to have a 
slur _at all_.


> > If anybody is planning something like that don't hesitate to contact
> > me. The production process probably would have been close to
> > impossible without tools like make, git, emacs and quite some lisp
> > coding and I don't mind sharing my experiences.
> [...]
>
> I use SCons, git, and vim, but same idea, I guess. :-) Especially git is
> indispensible when I need to experiment with different ways of working
> around a particular Lilypond limitation without losing track of where I
> was and/or accidentally losing data or introducing inadvertent mistakes
> in the score.

Add to this a setup with ~15 contributors ... :-)
But one thing I didn't go for is the automation of building and testing. 
Probably I'd give SCons a try, but I just didn't manage (particularly 
because along the way of the project I've somewhat become the only 
"project maintainer" out of originally two - which is a significant 
percentage, I think ...)

--
Urs Liska
www.openlilylib.org