[Top][All Lists]

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

Re: [PATCH] part combiner flexibility

From: Han-Wen Nienhuys
Subject: Re: [PATCH] part combiner flexibility
Date: Mon, 8 Sep 2008 10:40:13 -0300

On Mon, Sep 8, 2008 at 9:52 AM, Dan Eble <address@hidden> wrote:
>>>> If we go through with this (which I doubt), the handles_ should be a
>>>> vector<> so we get bounds checking.
>>> No argument there, but I don't understand what you mean by "which I
>>> doubt".
>> I doubt that we should have any sort of hard coded sequence of
>> different contexts to send music information to.
> Ah, I guess you want it even more flexible than I do.
> 1. What about an alist that tells which voice contexts to use for each state
> that is created by determine-split-list?  Something like ((apart . ("one"
> "two")) (solo1 . ("one" ())) ...) ?  Or callbacks?  It might not be that
> simple, since the part combiner does some things other than just switching
> contexts around.

Feel free to do what results in 1. a logical amount of flexibility  2.
clean code.  There is a lot of details that I forgot about how it
works, so it might be that not everything that I say makes sense.  The
original patch removes some hardcoding (good), but adds a lot of
properties (bad). If you can get around this, then it's OK.

> I was originally trying to change as little as possible, but if you're OK
> with it, I should probably try to address the quirks of mmrests now, so that
> we know they work from the start with the rest of the changes.

Sure - not that the current .scm code uses SCM vectors a lot, which is
not a very ergonomic abstraction.  You may want to use a more
high-level abstraction.

> 2. I notice that make-part-combine-music creates wraps its input in
> context-spec-music and the voice names "one" and "two" are hard-coded.
>  Would it be OK for it to check the type of the input music, and if it is
> already context-spec-music, don't wrap it?  I would change the part combiner

You could do that, but it's hard to make consistent,  eg.

 \partcombine \fooBarFunction \context Voice = foo

would not work, because fooBarFunction might insert another level of
hierarchy.  One way would be to try extract the context names in the
listener (see below).

> to get the names of the input voices from the music itself, instead of
> always using "one" and "two".
>>>> Should I also make partCombineChordRange a context property?
>> Yes, if possible.
> Is there a way to find the context from a music function, so I can get the
> property?

Oh right, you're in the .scm code.  If you need to have it at that
stage, a music-property is a lot easier.  The part combiner runs its
own interpretation step (see part-combiner.scm ,


which you could use to extract context property values, but it may be
a little hairy. IIRC you would have to setup a listener for the
set-property event, then you could contruct a moment => property-value

There have been discussions of the part combiner in the past
(including suggestions how to improve it). You may want to have a
gander in the archives to see if you find anything of value there.

The thread called

  partcombine, but including rests in quiet voices?

on lilypond-devel is the most recent of such.

Han-Wen Nienhuys - address@hidden -

reply via email to

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