Re: [partcombine] honouring Voice context name

[Carl Sorensen]

On 6/7/17 5:30 PM, "Kieren MacMillan" <address@hidden>
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