Re: Survey: Large scores

[H. S. Teoh]

On Fri, Apr 17, 2015 at 09:12:50PM +0200, Urs Liska wrote:
> Am 17.04.2015 um 20:44 schrieb H. S. Teoh:
[...]
> >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).

Thanks! I'll have to look into that sometime. That will certainly help
keep my input file clean and maintainable. Currently some parts of it
look very messy due to the amount of \partcombineApart,
\partcombineChords, etc.. (Not to mention other hacks like using \tag
for alternating between notation to be printed vs. notes to be sent to
the MIDI output. But the latter is not a problem if all you're looking
to produce is the printed score.)


> >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.

Well, the default setting is \partcombineAutomatic, and usually it works
relatively well. Only for the short segments for which it doesn't, I
will insert the other \partcombine* directives, immediately followed by
a reset to \partcombineAutomatic at the end of the problematic passage.
At least so far, I haven't run into any major snags yet. I actually have
my instrument parts completely separated, e.g., I have variables
"fluteIPart" and "fluteIIPart" that contain the entire part for each
respective instrument; I only use \partcombine at the containing scope
where I define the flute staff:

        fluteIPart = ... % entire part for first flute

        fluteIIPart = ... % entire part for second flute

        flutes = \new Staff = "flutes" {
                \set Staff.instrumentName = "flutes"
                ...
                \partcombine \fluteIPart \fluteIIPart
        }

        ... % later on I write \flutes to place the staff in the main score.


> >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.

Very true, the user shouldn't have to resort to hacks of this sort to
make things work. We really need to give \partcombine some TLC so that
it works better than it currently does. (Unfortunately I don't know the
Lilypond code too well yet, so I don't really feel ready to tackle such
a complex task yet.)


[...]
> 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_.

Oh. Yikes. I guess I've been lucky enough not to run into this yet...
But yeah, \partcombine needs a lot of work.


[...]
> >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 ...)
[...]

It's not that much different from make, really, at least as far as
Lilypond scores go. Or at least, as far as my own Lilypond projects go.
So far, I've kept my entire score in a single file (besides some generic
macros and scheme functions that I put in separate, reusable files) -- I
have a pretty rigid structure that I stick to, with various search
markers placed in comments at fixed points in the file, so that I can
easily navigate the file with vim's search function. So far it has
worked well.  But I can see how this could turn into a big mess once
multiple people start working on the same file, and not everyone uses
the same conventions...


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.