No need to pass the context modifications through the lower-level
functions, when they can be applied at the level of the \partcombineUp
music function as Dan does now in his lilypond input. These
modifications do not affect the operation of \partcombine, but are
merely added to its output so they should not be arguments to
\partcombine.
https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc
File lily/part-combine-iterator.cc (right):
https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc#newcode37
lily/part-combine-iterator.cc:37: = {"one", "two", "shared", "solo",
"null"};
Setting these to one, two, one, one, null
seems to do what Dan wishes.
If these names could be changed, maybe through a signal carried by a
music property, then we could name them
innerUp, outerUp, innerUp, innerUp, null
innerDown, outerDown, innerDown, innerDown, null
for partcombine Up/Down and two pairs of partcombined pares co-exist on
the staff.
https://codereview.appspot.com/13242056/diff/26001/lily/part-combine-iterator.cc#newcode388
lily/part-combine-iterator.cc:388: apply_property_operations (solo,
mod->get_mods ());
Maybe do this at the Scheme level, in the \partcombine* music functions?
https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly#newcode1168
ly/music-functions-init.ly:1168: #{ \partcombine \with { \voiceOne }
\with { \voiceOne } #part1
On 2014/11/01 15:26:57, Dan Eble wrote:
In one way, this is cleaner than what I currently have to do to
modify
one/share/two context properties. (That is refer to the voice
contexts in
parallel with \partcombine and set their properties.) One thing I
like about
this is that I don't have to rely on the names of the voices that
\partcombine
creates. One thing I don't like about it is that I'll have to consult
the
manual to check which context mods apply to "shared" and which apply
to all. I
see nothing mnemonic about their position.
I don't think the idea was for users to use these optional parameters,
but only the wrapper functions \partcombine{Up,Down}
Stepping back, for the \partcombineUp use case, I think it would make
more
sense for the partcombiner to distribute the input notes into just
two
voices instead of [four].
I think it could rather easily be changed to do that.
https://codereview.appspot.com/13242056/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
