Hi Dan and Keith,
I just wanted to let you know that I'm following your discussion with
interest, although I don't understand most of it. Any improvements in
the partcombiner are highly welcome and appreciated.
If there's anything I can do to help (without understanding more than
basic Scheme and without any option to help on the C++ part) please let
me know. Maybe it helps that I'm currently working on a big orchestral
score?
Best
Urs
Am 01.12.2014 08:30, schrieb Keith OHara:
On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble <d...@faithful.be> wrote:
I have a question. If the Scheme code produces something like
(‘apart “one” “two”) with “one” and “two” being the chosen output
voices for the input parts at the moment, would it make sense to
write those decisions back to the input parts themselves and have the
iterator find them there? Would that allow finer control over the
routing than there is now (say different routing of simultaneous
events in the same part) or have any other advantages?
I thought about it. I'm not sure.
There is some reason that the existing \partcombine makes a separate
split-list, rather than embedding the results of the analysis in the
two parts. It might be simply because part_combine_iterator normally
looks only at properties of the PartCombineMusic itself, not the
sequential music contained within.
The question seems to be whether the results of the analysis of
\partcombine mostly describes the state of the combined parts, or
mostly information about individual parts.
I suggest looking over the existing partcombine bugs, and orchestral
scores, to see what problems generally need solving.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
