|
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?
Thanks, -- Dan
[Prev in Thread] | Current Thread | [Next in Thread] |