On 6/7/17 5:30 PM, "Kieren MacMillan" <kieren_macmil...@sympatico.ca> wrote:
>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Š It seems to me that one of the issues that muddies the water here is the definition of what a "part" is that is to be combined by partcombine. Currently partcombine works on music expressions, IIUC. And the music expressions need not have contexts assigned. Therefore there are no context properties available in the items to be combined. So the current partcombine creates the named voices (if they don't already exist) and puts the music events into the appropriate voices. I don't want to contradict Dan, because he has done stuff with partcombine that is clearly beyond my contributions, but I think that my most common use case is not continuous parts in exactly one Voice context per part. I think my most common use case is two sequential music expressions that are not yet assigned to any Voice context. Is there something in partcombine that has the arguments be music in a Voice context? If so, I am not aware of it (but as I said before, my understanding of partcombine is fuzzy enough that this is certainly a question, not a statement). Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
