I'd be down for helping out with commissioned engraving work, but I think it raises some issues with which I have not yet made myself familiar within Lily's workflow. Primarily, how is the work distributed? Does each participant get individual parts, while a general editor makes sure things line up and interrelate properly? Are there already projects going on for this sort of thing?
It seems to me a good approach would be to set up a pool of engravers, and then send out calls for time when an actual job comes up. Like I said, I'd be happy to help, mainly out of my interest in getting into the finer points of making scores look exceptionally good. My current project is also somewhat large: I'm to engrave at least one mass (out of five, the one that's already transcribed being over 700 measures for four solo voices, satb, basso continuo, and a small string/brass/percussion group), one or more Catatas, and some Psalms from one obscure mid-18th-century composer from some monastery in the region. (As I've mentioned on the list before, the intended publisher of the score is *extremely* skeptical of Lily, to the point that I have to provide work samples to prove I can meet their in-house standards (which, alas! comprise almost entirely of using the default settings of *some commercial software I won't name*, and then manually tweaking all the ways it screws up the layout). My interest, then, is on the fine-tuning intended to make a scholarly edition look *pristine*, and I'm presently too much of a neophyte to know how to do that (or even where to start). But I'm willing to lend a hand, if it's helpful. Cheers, A On Fri, Apr 17, 2015 at 9:12 PM, Urs Liska <u...@openlilylib.org> wrote: > 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 > > > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user >
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
