[Top][All Lists]

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

Re: [PATCH] part combiner flexibility

From: Dan Eble
Subject: Re: [PATCH] part combiner flexibility
Date: Mon, 8 Sep 2008 08:52:08 -0400

On 7 Sep 2008, at 23:08, Han-Wen Nienhuys wrote:

On Sun, Sep 7, 2008 at 7:13 PM, 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.

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.

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


reply via email to

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