> On Jun 7, 2017, at 09:34, Kieren MacMillan <kieren_macmil...@sympatico.ca> > wrote: > > 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 we’re going to ask that kind of question, let’s mention a more radical redesign. The context properties of a part, such as stem direction, need to change as the part’s relationship with other parts changes. The current part combiner accomplishes this with a set of voices with fixed properties. It slices the part into pieces and distributes them to the voice with the appropriate properties. Could it not leave the parts where they are (continuous parts in exactly one voice context per part) and change their context properties instead? >> 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. I’m not sure I was clear. Those are examples of things I’ve actually accomplished using most of the scheme parts of the part combiner as shipped with Lilypond. I was trying to point out that there is already more internal flexibility than meets the eye. Depending on your use cases, you might already be able to take advantage of it. — Dan _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
