Re: [PATCH] part combiner flexibility

2008-09-08 Thread Han-Wen Nienhuys
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

Re: [PATCH] part combiner flexibility

2008-09-08 Thread Dan Eble
On 7 Sep 2008, at 23:08, Han-Wen Nienhuys wrote: On Sun, Sep 7, 2008 at 7:13 PM, 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

Re: [PATCH] part combiner flexibility

2008-09-07 Thread Han-Wen Nienhuys
On Sun, Sep 7, 2008 at 7:13 PM, 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

Re: [PATCH] part combiner flexibility

2008-09-07 Thread Dan Eble
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". 1. why is this a music property? Since it is all about contexts, I think a context property would be better,

Re: [PATCH] part combiner flexibility

2008-09-07 Thread Han-Wen Nienhuys
Some random comments: + // these contexts have a many-to-one relationship to handles_[] + struct Part_combine_outlets + { +Context *null; +Context *apart1; +Context *apart2; +Context *solo1; +Context *solo2; +Context *chords; +Context *rests; + } ctx_; + + // uniqu