Re: SDK Available
Re: SDK Available
- Subject: Re: SDK Available
- From: Bill Stewart <email@hidden>
- Date: Mon, 5 May 2003 18:17:16 -0700
What a lot of email...
Just to reiterate this... this has *always* been the case with
AUEffectBase unless you don't use alot of the things that it does do...
(like use its kernels).
All that the recent revision has done is to make explicit and more
solid the validation of formats at Initialization and thus removing the
need to validate these in the render call (not a good place to do it!)
And yes, Marc, I also understand your point about reusing code and have
a vast personal dislike for the copy paste approach to class design...
Summing up what you and others have said - it seems to me that what we
really need is an inheritance structure that is something like:
AUBase
-> An Effect Base class the supports what ANY effect should support
(don't care about channels in-out)
-> An Extension that adds the kernels that are ideal for using N-N
processing
If you have subclassed AUEffectBase in the past to do N-M processing -
then you will need to fix your Initialization calls.
The code that Marc posted recently seems a fine and general way to do
this.
Bill
On Monday, May 5, 2003, at 11:56 AM, Chris Rogers wrote:
On Mon, 5 May 2003, bakker35 wrote:
In the new AUEffectBase.cpp:
// The base class only really supports effects that have the same
number of
// channels in and out - so we check here that this is the case
if ((GetNumberOfChannels() !=
GetInput(0)->GetStreamFormat().mChannelsPerFrame) ||
(GetNumberOfChannels() == 0))
Since when is it a feature of AUEffectBase to always have the same
number
of inputs as outputs ? This one made made go back to the older
version.
(Marc Poirier writes) I agree. :) And I guess you must have missed
the thread about this
(AUEffectBase and Stream formats) which is still continuing now:
AUEffectBase has always implemented its rendering using "kernel"
objects (one per channel) so it's always been limited to n -> n
processing. For those effects which need more flexibility our approach
has been to inherit from AUBase directly. If you look at AUEffectBase,
all it really does it a bunch of stuff relating to these
AUKernelBase objects and you would have to override a number of virtual
methods anyway, so why not just inherit from AUBase directly for
effects which are not n->n rather than completely repurpose the added
function in AUEffectBase. In retrospect AUEffectBase may have been
poorly named, since it's not really the best base class for all types
of effects. Maybe we should have named it AUEffectBaseNtoN or
something like that...
Chris Rogers
Core Audio
Apple Computer
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.