Re: Survey: Large scores

[Urs Liska]

Am 18.04.2015 um 00:33 schrieb 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,

I don't think that engraver will make the \partcombineXXX stuff 
obsolete. But you can leave out the tag constructs to avoid duplicate texts.
I will try to make that easily available in openLilyLib soon (if I 
should remember to do so when I have the time for it).

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

Of course that's what I have too. But in the score I'm currently working 
on there are numerous issues that have to be dealt with manually. Maybe 
that's due to lots of independent dynamics and phrasings in the voices?

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

Fortunately there is one person who is actively working on the 
partcombiner, so I think there *is* some improvement currently. So we 
*do* have some progress right now. But I don't know how the time he can 
put into that relates to the time that would be necessary to bring the 
partcombiner to a professional level as a whole. Somehow it feels the 
partcombiner is something that might be better of redone completely ...

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

That doesn't help me because my experience with make is limited to using 
it for compiling source distributions ;-)

But I'd go for SCons because it's Python and I assume it would be quite 
natural to integrate it in Python based constructs.

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

Seems like quite the opposite of my approach (see 
http://lilypondblog.org/2014/10/segment-grid/)
find . -name "*.?ly" | wc -l returns 2917 for the project ;-)

But of course either approach is valid as long as it suits the 
personal/project set-up.

Best
Urs

> T