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. 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, 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., 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. 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've figured out that the current harakiri-spanner-group code is actually capable of achieving what I want, it just requires a custom engraver to set the right internal variables. I actually wrote a Scheme engraver that does this, and it's able to figure out the correct settings, but can't actually set them because there is currently no way to create a grob array from Scheme. I modified the C++ code to allow this, but I must've done something wrong 'cos while the setting is visible from Scheme, it for some reason is invisible to the C++ harakiri-spanner-group code. Anyway, the point is that this aspect of Lilypond is a deficiency that definitely requires in-depth knowledge of Lilypond internals (including the C++ code!), and not something users should be expected to do. I plan to submit a patch for this once I figure it all out so that others don't have to deal with it, but that may not be for a while yet. I'm curious how you dealt with this issue, or worked around it -- basically it comes up when I have a "frenched" orchestral score (i.e. with \RemoveEmptyStaves) and would like the tempo and rehearsal marks duplicated above the brass and strings, but to elide these marks from the corresponding choir when the entire choir is quiet and omitted from the page. Do you just manually duplicate the marks in each staff where they need to appear? > 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. T -- Just because you survived after you did it, doesn't mean it wasn't stupid! _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
