On Mon, Sep 8, 2008 at 9:52 AM, Dan Eble <[EMAIL PROTECTED]> 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 ,
recording-group-emulate
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
mapping
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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
