Re: Part combiner: separate split state and voice names
Keith OHara writes:
> Urs Liska openlilylib.org> writes:
>
>> Keith wrote:
>> > I suggest looking over the existing partcombine bugs, and orchestral
>> > scores, to see what problems generally need solving.
>
>> If there's anything I can do to help (without understanding more than
>> basic Scheme and without any option to help on the C++ part) please let
>> me know. Maybe it helps that I'm currently working on a big orchestral
>> score?
>
> I remember that you were once trying to define \new Voices in the music
> you gave to \partcombine (but it seems you decided you did not need to) :
> http://lists.gnu.org/archive/html/lilypond-user/2014-10/msg00509.html
> This doesn't work because \partcombine rearranges the music into Voices
> that it defines, with names "one" "two" "shared" "solo". With the color
> coding below, you can see that LilyPond's layout receives notes in four
> distinct voices from \partcombine.
>
> soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
> alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
> \new Staff <<
> \context Voice = "one" { \override NoteHead #'color = #red }
> \context Voice = "two" { \override NoteHead #'color = #green }
> \context Voice = "shared" {\override NoteHead #'color = #blue }
> \context Voice = "solo" {\override NoteHead #'color = #grey }
> \partcombine \soprano \alto >>
>
> Dan has for a long time wanted to be able to control which voices get
> which notes, while still having \partcombine do the tedious work of
> finding where the parts can be joined into chords, figuring rests,
> etc.
Well, in the category "dumb tricks with context definitions" we can
crank out the following:
soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
\new Staff <<
\context Voice = "one" {
\context VoiceAlias = "shared" { }
\override Voice.NoteHead #'color = #red
}
\context Voice = "two" { \override NoteHead #'color = #green }
\context Voice = "solo" {\override NoteHead #'color = #grey }
\partcombine \soprano \alto
>>
\layout {
\context {
\Voice
\accepts "VoiceAlias"
}
\context {
\name "VoiceAlias"
\alias "Voice"
\type "Engraver_group"
}
}
Something like this might also help for defining the "main voice" in
<< \\ >> split voices.
But it does beg the question whether these kinds of trick are not an
indication that we are lacking some better interfaces. Something like
\partcombine \with { "one" = "solo" } ...
would of course be feasible but that does not buy us an input strategy
for << \\ >> yet.
At any way, this particular trick requires issue 3225 (version 2.17.14
or later) to work.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
Urs Liska openlilylib.org> writes:
> Keith wrote:
> > I suggest looking over the existing partcombine bugs, and orchestral
> > scores, to see what problems generally need solving.
> If there's anything I can do to help (without understanding more than
> basic Scheme and without any option to help on the C++ part) please let
> me know. Maybe it helps that I'm currently working on a big orchestral
> score?
I remember that you were once trying to define \new Voices in the music
you gave to \partcombine (but it seems you decided you did not need to) :
http://lists.gnu.org/archive/html/lilypond-user/2014-10/msg00509.html
This doesn't work because \partcombine rearranges the music into Voices
that it defines, with names "one" "two" "shared" "solo". With the color
coding below, you can see that LilyPond's layout receives notes in four
distinct voices from \partcombine.
soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1}
alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1}
\new Staff <<
\context Voice = "one" { \override NoteHead #'color = #red }
\context Voice = "two" { \override NoteHead #'color = #green }
\context Voice = "shared" {\override NoteHead #'color = #blue }
\context Voice = "solo" {\override NoteHead #'color = #grey }
\partcombine \soprano \alto >>
Dan has for a long time wanted to be able to control which voices get
which notes, while still having \partcombine do the tedious work of
finding where the parts can be joined into chords, figuring rests, etc.
For example, it seems that "one" "shared" and "solo" could be reduced to one
Voice, allowing us to continue dynamics from a solo part into a2, for example,
when we force the transition with \partcombineChords.
Dan's recent question was whether two notation elements from the same 'part'
(e.g. FluteII) at the same moment, might ever need to go into to different
LilyPond Voices for purposes of layout. The current mechanism describes, at
any moment in time, the state of the combined music: unison, chords, solo, etc.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
Hi Dan and Keith, I just wanted to let you know that I'm following your discussion with interest, although I don't understand most of it. Any improvements in the partcombiner are highly welcome and appreciated. If there's anything I can do to help (without understanding more than basic Scheme and without any option to help on the C++ part) please let me know. Maybe it helps that I'm currently working on a big orchestral score? Best Urs Am 01.12.2014 08:30, schrieb Keith OHara: On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble wrote: I have a question. If the Scheme code produces something like (‘apart “one” “two”) with “one” and “two” being the chosen output voices for the input parts at the moment, would it make sense to write those decisions back to the input parts themselves and have the iterator find them there? Would that allow finer control over the routing than there is now (say different routing of simultaneous events in the same part) or have any other advantages? I thought about it. I'm not sure. There is some reason that the existing \partcombine makes a separate split-list, rather than embedding the results of the analysis in the two parts. It might be simply because part_combine_iterator normally looks only at properties of the PartCombineMusic itself, not the sequential music contained within. The question seems to be whether the results of the analysis of \partcombine mostly describes the state of the combined parts, or mostly information about individual parts. I suggest looking over the existing partcombine bugs, and orchestral scores, to see what problems generally need solving. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble wrote: I have a question. If the Scheme code produces something like (‘apart “one” “two”) with “one” and “two” being the chosen output voices for the input parts at the moment, would it make sense to write those decisions back to the input parts themselves and have the iterator find them there? Would that allow finer control over the routing than there is now (say different routing of simultaneous events in the same part) or have any other advantages? I thought about it. I'm not sure. There is some reason that the existing \partcombine makes a separate split-list, rather than embedding the results of the analysis in the two parts. It might be simply because part_combine_iterator normally looks only at properties of the PartCombineMusic itself, not the sequential music contained within. The question seems to be whether the results of the analysis of \partcombine mostly describes the state of the combined parts, or mostly information about individual parts. I suggest looking over the existing partcombine bugs, and orchestral scores, to see what problems generally need solving. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Nov 30, 2014, at 01:17 , Keith OHara wrote: > > If \partcombine can only assume part of the responsibility for routing > decisions, though, I seems cleaner to enhance the set of split-state tags to > completely describe the results of \partcombine's analysis, rather than tell > part_combine_iterator (partially) how to do its job. I am optimistic that the Scheme code can take over the full analysis. Another reason to risk trying this is that naming combined routing decisions like silence1, silence2, etc. does not scale well to combining N parts. I have a question. If the Scheme code produces something like (‘apart “one” “two”) with “one” and “two” being the chosen output voices for the input parts at the moment, would it make sense to write those decisions back to the input parts themselves and have the iterator find them there? Would that allow finer control over the routing than there is now (say different routing of simultaneous events in the same part) or have any other advantages? Of course the summary of the combined state still needs to be provided for generating the partcombine text, and that seems to work just fine. I’m only suggesting writing the voice routing decisions back into the corresponding inputs. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
"Keith OHara" writes:
> I am eager for either nameable outputs from \partcombine, or
> VoiceGroup, in LilyPond so we can have a stable and functional
> \partcombineUp/Down.
VoiceGroup won't help with merging multiple outputs into one context.
We'd need something like
\context Voice = "unisilence" = "silenceone" { ... }
for that, and that looks like a real ugly bag of worms. I think that it
would make more sense to give \partcombine the capability not to use
hardwired names only, and to behave sensibly where several names are
identical.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sat, 29 Nov 2014 18:09:34 -0800, Dan Eble wrote:
On Nov 29, 2014, at 18:48 , Keith OHara wrote:
Oh, so you meant let the Scheme portion dictate to partcombine_iterator which
_input_ voice, as it iterates the music expression produced by \partcombine, to
use.
My reasoning probably needs more clarification. The iterator takes sequences
of events and routes them into voices. So, I thought that where now the Scheme
portion produces simply ‘unisilence, it might produce something like (’silence
“shared” #f) to tell the iterator that both parts are silent, the first part
should be placed into the voice named “shared”, and the second part should be
dropped. That’s what I meant by telling the iterator which output voice to use.
Telling the iterator which input to use would be something like defining new
states ‘unisilence1 and ‘unisilence2.
Adding the new split-state tags 'unisilence1' and 'unisilence2' would preserve
the relative roles of the \partcombine function and the part_combine_iterator
The function \partcombine analyzes the music to describe which part or parts
must be printed and when they should be combined in chords. That analysis is
what you want to improve so that
\partcombine {R1 R1} {R1 r4 b2.}
reports that the first beat of the second measure is not really 'unisilence',
but 'silence2'.
The part_combine_iterator takes the results of \partcombine and decides what
events to send to what Voices.
Maybe you can make \partcombine completely take over the routing decisions.
Then maybe the iterator would be reduced to following orders, and keeping track
of which voices need to start or stop multimeasure rests.
If \partcombine can only assume part of the responsibility for routing
decisions, though, I seems cleaner to enhance the set of split-state tags to
completely describe the results of \partcombine's analysis, rather than tell
part_combine_iterator (partially) how to do its job.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Nov 29, 2014, at 18:48 , Keith OHara wrote: > > Oh, so you meant let the Scheme portion dictate to partcombine_iterator which > _input_ voice, as it iterates the music expression produced by \partcombine, > to use. My reasoning probably needs more clarification. The iterator takes sequences of events and routes them into voices. So, I thought that where now the Scheme portion produces simply ‘unisilence, it might produce something like (’silence “shared” #f) to tell the iterator that both parts are silent, the first part should be placed into the voice named “shared”, and the second part should be dropped. That’s what I meant by telling the iterator which output voice to use. Telling the iterator which input to use would be something like defining new states ‘unisilence1 and ‘unisilence2. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Nov 29, 2014, at 18:48 , Keith OHara wrote: > > On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble wrote: > >> This suggestion was motivated by recent work on cases in which both parts >> are resting. If the desired action is to route only one of the voices to the >> shared voice, the Scheme half currently can only say “unisilence” and the >> Part_combine_iterator picks a voice. The problem is that sometimes it >> doesn’t pick well. It seems that the Scheme half has the information to >> make a better decision. > > Oh, so you meant let the Scheme portion dictate to partcombine_iterator which > _input_ voice, as it iterates the music expression produced by \partcombine, > to use. > > That makes more sense. However, the current problem with the iterator > picking which input part to route to output Voice "shared", seems best solved > by your current patch, that marks these situations as 'apart-silence' > whenever there is a difference between the input parts. The current patch[1] improves many cases, but there are cases it doesn’t handle as well as could be handled, Exhibit A being the regression test that changed. That case has a rest concurrent with a multi-measure rest. The Scheme code could easily decide that the multi-measure rest is visually unnecessary, but there is no way for it to tell the current Part_combine_iterator specifically, “Both parts are silent; keep the first part and discard the second.” [1] https://code.google.com/p/lilypond/issues/detail?id=4205 — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble wrote: On Nov 29, 2014, at 16:46 , Keith OHara wrote: Dan Eble faithful.be> writes: I would like the Scheme portion of the part combiner to dictate the names of the voices to use at every moment. Simply letting us specify the Voices _once_ for the whole output of \partcombine would help a lot. It would, and I’m glad you’re encouraging me to dig up my ancient patch to do that, but I wasn’t thinking of making any user-visible changes in the scope of the work suggested in this thread. (That could come later.) Well, if I can't use it, I am less motivated to review it. I am eager for either nameable outputs from \partcombine, or VoiceGroup, in LilyPond so we can have a stable and functional \partcombineUp/Down. Include an example in your patch, where we want to rearrange the routing of soloI, unison, etc., to Voices mid-piece. This suggestion was motivated by recent work on cases in which both parts are resting. If the desired action is to route only one of the voices to the shared voice, the Scheme half currently can only say “unisilence” and the Part_combine_iterator picks a voice. The problem is that sometimes it doesn’t pick well. It seems that the Scheme half has the information to make a better decision. Oh, so you meant let the Scheme portion dictate to partcombine_iterator which _input_ voice, as it iterates the music expression produced by \partcombine, to use. That makes more sense. However, the current problem with the iterator picking which input part to route to output Voice "shared", seems best solved by your current patch, that marks these situations as 'apart-silence' whenever there is a difference between the input parts. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Nov 29, 2014, at 16:46 , Keith OHara wrote: > > Dan Eble faithful.be> writes: > >> I would like the Scheme portion of the part >> combiner to dictate the names of the voices to use at every moment. > > Simply letting us specify the Voices _once_ for the whole output of > \partcombine would help a lot. It would, and I’m glad you’re encouraging me to dig up my ancient patch to do that, but I wasn’t thinking of making any user-visible changes in the scope of the work suggested in this thread. (That could come later.) > Include an example in your patch, where we want to rearrange the routing > of soloI, unison, etc., to Voices mid-piece. This suggestion was motivated by recent work on cases in which both parts are resting. If the desired action is to route only one of the voices to the shared voice, the Scheme half currently can only say “unisilence” and the Part_combine_iterator picks a voice. The problem is that sometimes it doesn’t pick well. It seems that the Scheme half has the information to make a better decision. One way to handle this would be to add named states for other useful routing combinations, like dividing “unisilence” into “unisilence1” and “unisilence2”. I figured that might get out of hand. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
Dan Eble faithful.be> writes:
> I would like to break the rigid link between the split states
> (apart, unisilence, etc.) and the names of the
> voices into which the Part_combine_iterator routes events.
The patch back at
http://lists.gnu.org/archive/html/lilypond-devel/2008-09/msg00079.html
makes sense, and seems flexible enough. The awkward part was naming
the Voice contexts for the four states of music. Given that you need
that information in the output of \partcombine
pc = \displayMusic \partcombine {b2 b ...} {b2 b ...}
for the iterator to see, it seems that music properties are the only
places to put it. Maybe one property that takes the full list of context
names...
> I would like the Scheme portion of the part
> combiner to dictate the names of the voices to use at every moment.
Simply letting us specify the Voices _once_ for the whole output of
\partcombine would help a lot.
Include an example in your patch, where we want to rearrange the routing
of soloI, unison, etc., to Voices mid-piece.
The example in the 2008 thread, setting unison directions, is better done
with \context Voice="shared" {\voiceOne} than by changing Voices.
The first use I can imagine is that I would usually want the shared Voice
to be identical with the first-part Voice, but sometimes would want the
shared events to go to the second-part Voice. In that case, I am thinking
of the Voice output arrangement all at once, so specifying a list of four
is natural.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Part combiner: separate split state and voice names
To those familiar with the part combiner: I would like to break the rigid link between the split states (apart, unisilence, etc.) and the names of the voices into which the Part_combine_iterator routes events. I would like the Scheme portion of the part combiner to dictate the names of the voices to use at every moment. This probably needs to be an addition to the split state name, not a replacement of it, but I’m not sure of that. I expect the Part_combine_iterator to become much simpler. I hope that the ability to route events in new ways without having to name each combination will simplify fixing some bugs and adding features. If you would encourage or discourage me from this, please speak up. I expect to experiment with it as I find time. Regards, — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
