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

[dak]

On 2015/10/01 22:07:28, Dan Eble wrote:
> 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.

I think that's the wrong way to do things.  I'm open to using a GUILE
structure for keeping the governing state of the partcombiner in.  But
then it should not be restricted to the initial state but should reflect
the current state.  One can have a separate copy of the state to reflect
"\once" settings.  And there likely should be a function that
initializes the current state from current context properties: that way
one can make any parameters to the part combiner a context mod, and then
one just initializes the voices from the recording group emulator with
that context mod and generates the GUILE structure from the resulting
state of the context.

That way you can just store specific settings in context mods and pass
them to the part combiner in that manner.  How the part combiner
maintains its internal state is then its own business.

> 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 see that the part combiner will ever get along satisfactorily
without getting additional, mostly localized hints, and predicting the
form all of them may take seems audacious.

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

Sure, but having to rewrite your internals whenever one item should
become configurable on the fly seems just like shortsighted design.  I
don't see that it should significantly complicate matters to keep
current state rather than just initial state in your structure.

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

So?  We have \tag for doing that sort of thing conditionally, and of
course you can just put the whole timed information for one
partcombining pass into a separate variable and add it to one particular
use of the music by using << ... >>.

Once we are dealing with standard LilyPond entities, we have the tools
for working with those entities.

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

How the Scheme functions are fed is more or less an implementation
detail.  I'd try to keep any interfaces that have been along for a
reasonably long time, but refactoring behind that sort-of-established
interface can of course be done in manners that are nicer to juggle
with.  One should just make sure that the factoring is reasonably
straightforward, for example having a single function that can convert a
context into such a GUILE structure by looking at the respective context
properties.

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

I don't want to have too many different commands: we already have too
many of them.  Customization of the behavior should mostly be possible
using a context mod.  The partcombiner is less cluttered than the cue
commands currently I think: it's ridiculous that up/down and
transposition and clef all have separate commands with different names:
all of that can perfectly well be stuffed into a single context mod when
required.  That way one can be reasonably sure that one did not overlook
something to configure, and further extensions are painless and don't
require thinking about just what permutation of variations one wants to
creep into the command names.

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