[RTcmix-discuss] new delay allocation question

Douglas Scott netdscott at netscape.net
Tue Jan 11 13:43:28 EST 2005


Well, on closer inspection, I see that the interpolated versions already do it 
one better -- containing a pointer to an instance of the interpolated delay in 
the interpolated comb.  This is even better than a static function pointer.  I 
think the *non-interpolated* comb should work identically, and have the same 
public interface -- even though a floating-point delay length would be truncated 
to an int (or rounded), there is no reason why the calling routine (COMBIT, 
etc.) should have to care whether the underlying comb is interpolated or not. 
So, one possibility is Ocomb becoming the base class, which would contain a 
pointer to a delay object, which for the non-interpolated comb would be a 
non-interpolated delay.  Ocombi would derived from Ocomb, and the only 
difference is it would initialize itself with an interpolated delay object.  The 
delay object itself would be polymorphic, so the  two comb classes would never 
even know whether or not they interpolated (having two comb classes is just a 
convenience to allow the two different initializations).

Is that at all clear?

-DS


johgibso at indiana.edu wrote:

> 
> On Jan 11, 2005, at 12:32 PM, Douglas Scott wrote:
> 
>> As a matter of fact, ODelayi, Ocomb and Ocombi should be derived from 
>> Odelay, and most of the work should be done in the base class.  And 
>> the interpolation method should be contained, not inherited (John will 
>> get this, right, John?).  :-)
> 
> 
> You mean as static methods, like we did in PField.cpp?  You want
> to go ahead and make these changes to the Ougens?
> 
> JG



More information about the RTcmix-discuss mailing list