Re: Issue 4622: create a <Part-combiner> class (issue 265260043 by address@hidden)

[nine . fierce . ballads]

On 2015/10/01 08:33:11, dak wrote:
> into the user interface as well as extending the code.  Let's assume
that we
> make chord extent changeable on the fly via setting a context
property.  How
> would you implement that using your part combiner structure?

Then I would remove it from the structure.

For the force commands, it would be good to survey where they have been
used so far.
Some of them are obsolete now that the chord range is configurable.
Some of them could be blamed on bugs that should be fixed.
Some of them would be unnecessary with different state machines.
Some of them might be easily replaced with other work-arounds like
manual beams or invisible phrasing slurs.

I don't mean to say that there shouldn't be a method of working around
unwanted decisions, but that the number of situations in which they are
necessary probably does not justify a high level of elegance.  Really, I
couldn't care less how the force commands are implemented.

But I am skeptical about converting the chord range to a context
property because from what I have seen so far, it seems to involve
having the property-set commands within the parts being combined, and
that doesn't make sense.  Configuring the part combiner's decisions from
within the parts breaks down cases where a part might be used in
different ways in multiple situations:

  % flute.ly
  \include "hymn.ly"
  ... \partcombine \transpose c c' \tenor \soprano

  % violin.ly
   \include "hymn.ly"
   ... \partcombine \soprano \alto ...

  % viola.ly
  \include "hymn.ly"
  ... \partcombine \alto \tenor ...

I have collections that do that kind of thing.

Putting all that aside, what I really want in the near term is to reduce
the amount of Lilypond code I have duplicated with my compositions.
Without defining a <Part-combiner> class, I could still do that by
passing the chord range and state machines as individual arguments.
<Part-combiner> was a nice way to help me organize things on the way
there, but I could still achieve this goal without it.  Would you feel
any better about that?  Or do you think that it is proper for me to have
to make my own copy of make-directed-part-combine-music in order to use
the part combiner with different state machines?

Alternatively, if exposing the state machines as options to public
scheme methods is itself objectionable, what would be the reaction to my
submitting a patch with a new command that does exactly what I want (no
a2/solo passages) out of the box?

https://codereview.appspot.com/265260043/