Hi Dan, > If we’re going to ask that kind of question, let’s mention a more radical > redesign.
I would be happy with a "radical redesign", if that's what it takes to (a) solve some of the problems I face with partcombine on a daily basis, or (b) establish a good base for future development/improvement, or (c) both of the above. > 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? Not sure I quite understand what you're suggesting… > 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. Well, in regard to at least one of the problems I'm facing, David K has indicated that "the principles of the mechanisms are incompatible" (translation: can't use what's shipped with Lilypond). 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
