Re: [partcombine] honouring Voice context name
On 6/6/17 12:45 PM, "lilypond-devel on behalf of Kieren MacMillan"
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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
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: i...@kierenmacmillan.info ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
On Jun 6, 2017, at 15:30, Kieren MacMillan 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
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: i...@kierenmacmillan.info ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
> On Jun 7, 2017, at 09:34, Kieren MacMillan > 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
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: i...@kierenmacmillan.info ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
On 6/7/17 5:30 PM, "Kieren MacMillan" 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
Re: [partcombine] honouring Voice context name
> On Jun 7, 2017, at 19:48, Carl Sorensen wrote: > > On 6/7/17 5:30 PM, "Kieren MacMillan" > 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
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: i...@kierenmacmillan.info ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
Dan Eble writes: >> On Jun 7, 2017, at 09:34, Kieren MacMillan >> 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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [partcombine] honouring Voice context name
From: David Kastrup To: Dan Eble Cc: Kieren MacMillan , LilyPond Development Team Bcc: Date: Thu, 08 Jun 2017 12:03:04 +0200 Subject: Re: [partcombine] honouring Voice context name Dan Eble writes: >> On Jun 7, 2017, at 09:34, Kieren MacMillan >> 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*" ela...@flaminghakama.com self-immolation.info skype: flaming_hakama Producer ~ Composer ~ Instrumentalist -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
