Hi Dan, > 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?
Absolutely. As a first step, I would offer that we should figure out how (if?) the "one" context can be funnelled seamlessly into the "shared" and "solo" contexts — as I see it, that's the main problem with lyrics getting disconnected (etc.). > 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? An excellent question. I would love to be that [swash]buckler, but given the combinatorial growth rate of the possible multi-voice interactions, I currently don't have an inkling how to scale the partcombiner to *three* voices, let alone "arbitrary". I'm hoping tackling and perfecting [sic] the two-voice version will give me better insights in that direction. > 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”. See above; I'm hoping the voice names *will* impact the algorithm (in a positive sense). > 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 That doesn't sound quite right to me… > 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.) I'll look at that. Thanks. > 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. I'll try (1), unless I hear or find something that suggests I should do otherwise. Thanks! Kieren. ________________________________ Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel