[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
- [partcombine] honouring Voice context name, Kieren MacMillan, 2017/06/06
- Re: [partcombine] honouring Voice context name, Carl Sorensen, 2017/06/06
- Re: [partcombine] honouring Voice context name, Kieren MacMillan, 2017/06/06
- Re: [partcombine] honouring Voice context name,
Dan Eble <=
- Re: [partcombine] honouring Voice context name, Kieren MacMillan, 2017/06/07
- Re: [partcombine] honouring Voice context name, Dan Eble, 2017/06/07
- Re: [partcombine] honouring Voice context name, Kieren MacMillan, 2017/06/07
- Re: [partcombine] honouring Voice context name, Carl Sorensen, 2017/06/07
- Re: [partcombine] honouring Voice context name, Dan Eble, 2017/06/07
- Re: [partcombine] honouring Voice context name, Kieren MacMillan, 2017/06/07
- Re: [partcombine] honouring Voice context name, David Kastrup, 2017/06/08