lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [partcombine] honouring Voice context name


From: Dan Eble
Subject: Re: [partcombine] honouring Voice context name
Date: Tue, 6 Jun 2017 23:57:06 -0400

On Jun 6, 2017, at 15:30, Kieren MacMillan <address@hidden> wrote:
> 
>> I guess what you are saying is that if the parts to be combined are each
>> context-specced-music, use those contexts.
> 
> Exactly.

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?

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?

>> If they are not, use the default contexts.
> 
> In that case, wouldn't parameterized (rather than internally hardcoded) names 
> help avoid problems like spanners breaking, lyrics being disconnected from 
> their associatedVoice, and so forth?

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”.

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
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.)

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.

Regards,
— 
Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]