[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown funct

From: dak
Subject: Re: Issue 1321: Enhancement: add partcombineUp and partcombineDown functions (issue 13242056)
Date: Sat, 01 Nov 2014 17:27:39 +0000
File ly/ (right):
ly/ #{ \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
creates.  One thing I don't like about it is that I'll have to consult
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
\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

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"

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]