On Jun 6, 2017, at 15:30, Kieren MacMillan <kieren_macmil...@sympatico.ca> wrote: > >> I guess what you are saying is that if the parts to be combined are each >> context-specced-music, use those contexts. > > Exactly.
The part combiner can also route events to “shared”, “solo”, and “null” contexts. If you took the step you’re proposing, the next question would be why can’t a person control those other names too? If there is going to be user control, should it be more comprehensive? If it should be more comprehensive, the next question is will it scale if someone finally buckles down and makes the part combiner work with more than two parts? >> If they are not, use the default contexts. > > In that case, wouldn't parameterized (rather than internally hardcoded) names > help avoid problems like spanners breaking, lyrics being disconnected from > their associatedVoice, and so forth? On the contrary, your suggestion seems aesthetic. Whether the up-stem voice is “one” or “fred” does not impact the algorithm. You'd still have one part jumping around between “fred”, “shared”, and “solo”. If you do want to impact the algorithm, it is possible to define a music function that uses the deeper parts of the part combiner with your own state machine. Variations I’ve tried: 1) never enter solo mode 2) add force commands \partcombineRovingI and ~II and corresponding voices “rovingOne” and “rovingTwo” to support staff splitting (I hoped to contribute this, but I haven’t had time.) Getting back to your idea: the state machine definition has voice names, so if you wanted to make the voice names flexible, I suppose you would either 1) use the existing state machine as a template: make a copy, replace the names, pass it on to the part combiner; OR 2) give the part combiner a map from the state-machine voice names to the user's voice names I’m not a good judge of which is more lispy. (1) strikes me as more complicated but probably better performing. Regards, — Dan _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
