Am 25.11.2014 14:50, schrieb Dan Eble:
On Nov 25, 2014, at 04:21 , Urs Liska <u...@openlilylib.org> wrote:
Is the following assumption correct?
At the beginning of m.2 the partcombiner treats the crotchet and the full
measure rests as two voices.
Yes. The part combiner directs those rests into voices “one” and “two”.
At the second crotched, when \one begins to play notes this is considered
"solo" because \two doesn't play at that moment.
Yes.
OK. Thanks for confirming.
In the meantime I've already sent a new bug report to bug-lilypond:
http://lists.gnu.org/archive/html/bug-lilypond/2014-11/msg00071.html
When I explicitly instantiate a "solo" voice in the \score block this will be
somehow merged with the voice implicitly created by the partcombiner.
Yes. You could do the same with voices “one”, “two”, and “shared”.
Ah, yes, that's something I had intended to ask but forgot.
Maybe this may help me solving a few other issues in our score.
OK. It seems this may be a way to fix all issues with the output but as you say
it's not pretty. Actually I'd say it's inacceptably ugly. In my concrete score
this would mean I'd have to write such a dummy voice for the 800 measure piece,
for all partcombined instruments.
In a work of that scale, I agree.
The scale of the score just makes it inacceptably impractical to use.
But of course this is generally an area where one seems to need quite
hacky approaches. And probably not one I'll write a glorifying blog post
about ...
For my own work, which is mostly vocal and mostly short, I have modified the
part combiner never to create solo sections. When one part rests, both parts
are engraved; when both parts rest, they are combined into one. It sounds like
this is probably not what you need, but if it would help you, I could give you
a patch. I do not know when I will be able to contribute it to Lilypond
because I am trying to find a more general solution to part combiner
limitations.
On first sight this sounds like a viable solution for my case, so I'd
gladly try out the patch.
The problem is that I won't get (all) the contributors to run custom
builds, so I'd have to direct them at patching their installation
(assuming it's a Scheme-only patch), and I'm not so sure if that's
something everybody would like ...
Best
Urs
—
Dan
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
