[RTcmix-discuss] new delay allocation question
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?
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?
More information about the RTcmix-discuss