Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)

[dak]

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.

The end of the branch is actually another commit where the context mods
for first and second part are not part of the arguments.  Instead, you
use
\new Voice \with { ... } { ... }
to specify context mods that are only part of first and second part.
Then there is one optional context mod before the first part that counts
for all parts (in the most significant position), and one "shared"
before the first part (still awkward, yes) that's only active for shared
parts.

That commit is "work in progress", not yet finished.  It leaves a few
less things in the "I have to look the position up in the manual"
category.

Is that sufficient to be good?  I'm not sure.  It's really not easy to
come up with something that is flexible, extensible, and yet not "I have
to look this up constantly".

> In short, this is nice, but not clearly better than the status quo,
unless there
> is something I'm missing.

You are obviously not missing all too much since I did not get this
finished yet.  However, the main purpose would have been to make it easy
to add additional properties.

> 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 three.  Rather than putting notes into Voices "one" and "shared"
that need to
> be configured separately with the same context properties, just direct
all
> top-part notes into "shared" and never into "one."  That also has a
chance of
> making some things that would use or iterate over that voice work
better.
> Lyrics come to mind, though NullVoice is a good workaround nowadays.
I *think*
> it would improve the outcome of automatic beaming, but let me find an
example
> before you assume that I know what I'm talking about.

So far this is an area where the current codebase is useful for a lot
less than what it _could_ be the workhorse for, and a significant part
of that shortcoming is a reasonably flexible and extensible user
interface that still is not arbitrary to a degree to require looking in
the manual all the time.

https://codereview.appspot.com/13242056/