[partcombine] honouring Voice context name

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[partcombine] honouring Voice context name

Kieren MacMillan
Hello all,

I'm looking at make-directed-part-combine-music, and wondering why the voice names are hard-coded ("one" and "two")…

It seems to me that if a Voice context passed to partcombine is already named, that name should be honoured by partcombine. Only if the context is not already named should a name be added (for obvious programming reasons).

Is there any technical reason that I shouldn't consider rewriting make-directed-part-combine-music such that any previously-defined Voice context name is honoured?

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Carl Sorensen-3
On 6/6/17 12:45 PM, "lilypond-devel on behalf of Kieren MacMillan"
<lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of
[hidden email]> wrote:

>Hello all,
>
>I'm looking at make-directed-part-combine-music, and wondering why the
>voice names are hard-coded ("one" and "two")Š
>
>It seems to me that if a Voice context passed to partcombine is already
>named, that name should be honoured by partcombine. Only if the context
>is not already named should a name be added (for obvious programming
>reasons).

I don't think that Voice contexts are passed to partcombine in the current
usage (although I guess they can be).

My typical usage would be:

partOne = {Š}
partTwo = {Š}

\new Staff {
  \partcombine \partOne \partTwo
}

I guess one could have

partOne = \context Voice = voiceOne {Š}
partTwo = \context Voice = voiceTwo {Š}

\new Staff {
  \partcombine \partOne \partTwo
}

But it was my understanding that partcombine actually acts on the music
expressions, rather than as part of the iteration (which assigns the music
expressions to contexts).

But I haven't checked the source on this specific occasion.



>
>Is there any technical reason that I shouldn't consider rewriting
>make-directed-part-combine-music such that any previously-defined Voice
>context name is honoured?

I guess what you are saying is that if the parts to be combined are each
context-specced-music, use those contexts.  If they are not, use  the
default contexts.  It seems to me that could be a worthwhile approach.

Thanks,

Carl


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Kieren MacMillan
Hi Carl,

Thanks for the quick response.

> I guess what you are saying is that if the parts to be combined are each
> context-specced-music, use those contexts.

Exactly.

> 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?

A hardcoded internally-assigned name (e.g. "one") should be the last resort reserved for labelling expressions/contexts that didn't already have a name.

> It seems to me that could be a worthwhile approach.

Excellent. I'll look into what's required and report back.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Dan Eble
On Jun 6, 2017, at 15:30, Kieren MacMillan <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Kieren MacMillan
Hi Dan,

> 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?

Absolutely.

As a first step, I would offer that we should figure out how (if?) the "one" context can be funnelled seamlessly into the "shared" and "solo" contexts — as I see it, that's the main problem with lyrics getting disconnected (etc.).

> 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?

An excellent question. I would love to be that [swash]buckler, but given the combinatorial growth rate of the possible multi-voice interactions, I currently don't have an inkling how to scale the partcombiner to *three* voices, let alone "arbitrary". I'm hoping tackling and perfecting [sic] the two-voice version will give me better insights in that direction.

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

See above; I'm hoping the voice names *will* impact the algorithm (in a positive sense).

> 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

That doesn't sound quite right to me…

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

I'll look at that. Thanks.

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

I'll try (1), unless I hear or find something that suggests I should do otherwise.

Thanks!
Kieren.

________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Dan Eble

> On Jun 7, 2017, at 09:34, Kieren MacMillan <[hidden email]> wrote:
>
> As a first step, I would offer that we should figure out how (if?) the "one" context can be funnelled seamlessly into the "shared" and "solo" contexts — as I see it, that's the main problem with lyrics getting disconnected (etc.).

If we’re going to ask that kind of question, let’s mention a more radical redesign.

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?

>> 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
>
> That doesn't sound quite right to me…
>
>> 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.)
>
> I'll look at that. Thanks.

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.

Dan



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Kieren MacMillan
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: [hidden email]


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Carl Sorensen-3
On 6/7/17 5:30 PM, "Kieren MacMillan" <[hidden email]>
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Dan Eble

> On Jun 7, 2017, at 19:48, Carl Sorensen <[hidden email]> wrote:
>
> On 6/7/17 5:30 PM, "Kieren MacMillan" <[hidden email]>
> wrote:
>
>>> 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Š
>
> So the current partcombine creates the named voices (if they don't already
> exist) and puts the music events into the appropriate voices.
>
> 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.

I think we’re just looking at it differently.  You’re considering the arguments to partcombine.  My perspective was that eventually the events in those expressions are interpreted in a voice context.

I was trying to explain that there are two related aspects of the current implementation that might be unnecessary:

  * using more voices than there are parts
  * distributing fragments of a part to different voices

It is worth investigating the possibility of changing the part combiner from an event router to a property setter.  If that is feasible, Kieren’s concerns about voice naming would still need to be addressed, but without the complication of the extra voices that exist only as an implementation artifact.

Dan


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Kieren MacMillan
Hi Dan (et al.),

> It is worth investigating the possibility of changing the part combiner from an event router to a property setter.  If that is feasible, Kieren’s concerns about voice naming would still need to be addressed, but without the complication of the extra voices that exist only as an implementation artifact.

It's a very interesting idea. Whether it is scalable is possibly a separate concern… but even as an intentionally-limited mechanism (e.g., \combineTwo, which can only combine two parts/voices), there could be great benefits. I'll poke around and report back.

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

David Kastrup
In reply to this post by Dan Eble
Dan Eble <[hidden email]> writes:

>> On Jun 7, 2017, at 09:34, Kieren MacMillan
>> <[hidden email]> wrote:
>>
>> As a first step, I would offer that we should figure out how (if?)
>> the "one" context can be funnelled seamlessly into the "shared" and
>> "solo" contexts — as I see it, that's the main problem with lyrics
>> getting disconnected (etc.).
>
> If we’re going to ask that kind of question, let’s mention a more
> radical redesign.
>
> 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?

For shared/non-shared stems that would not seem to fit the current
logic.  Mind you: for piano music the rather rigid relation of stems and
slurs and noteheads with voices is a problem.

So changing this seems attractive but it would be a very fundamental
change.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partcombine] honouring Voice context name

Flaming Hakama by Elaine
In reply to this post by Kieren MacMillan
From: David Kastrup <[hidden email]>
To: Dan Eble <[hidden email]>
Cc: Kieren MacMillan <[hidden email]>, LilyPond Development
Team <[hidden email]>
Bcc:
Date: Thu, 08 Jun 2017 12:03:04 +0200
Subject: Re: [partcombine] honouring Voice context name
Dan Eble <[hidden email]> writes:

>> On Jun 7, 2017, at 09:34, Kieren MacMillan
>> <[hidden email]> wrote:
>>
>> As a first step, I would offer that we should figure out how (if?)
>> the "one" context can be funnelled seamlessly into the "shared" and
>> "solo" contexts — as I see it, that's the main problem with lyrics
>> getting disconnected (etc.).
>
> If we’re going to ask that kind of question, let’s mention a more
> radical redesign.
>
> 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?

For shared/non-shared stems that would not seem to fit the current
logic.  Mind you: for piano music the rather rigid relation of stems and
slurs and noteheads with voices is a problem.

So changing this seems attractive but it would be a very fundamental
change.

--
David Kastrup


This hints back to the broader topic, of what are the intended uses of the
grand unified partcombine. (And whether or how many of these are captured
in existing tickets.)

While it is ideal to design to handle all cases including the most
complicated, does anyone typically combine piano parts?   What is the
musical use-case for this?

Or, putting it another way, how general is the issue of the "rigid relation
of stems and slurs and noteheads" within parts that people will want to
combine?  My hunch is that they don't much overlap:  if you are adding
rigid structures, what makes you think you should be able to automagically
combine something with it?


HTH,

David Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
[hidden email]
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Loading...