Re: AUEffectBase and Stream formats
Re: AUEffectBase and Stream formats
- Subject: Re: AUEffectBase and Stream formats
- From: Bill Stewart <email@hidden>
- Date: Fri, 23 May 2003 15:01:50 -0700
Marc,
On Friday, May 23, 2003, at 02:23 PM, Marc Poirier wrote:
On Thu, 22 May 2003, Bill Stewart wrote:
Marc, et al,
So - rather than go the route of introducing a new base class, we've
gone over the kernel stuff, etc, and will continue to use AUEffectBase
as a general subclass for any channel valences... With the continued
advise that the kernel can be used for N->N effects, and for N->M
channel effects the ProcessBufferList method should be overwritten...
Thanks for attending to our needs, Bill. :)
My pleasure.
A couple of potential gotchas for those using this class for N->M
effects... both the base class' handling of the Bypass property and
processing inplace, need to be revisited - the base class' support for
both of these properties is contingent on N->N processing.
Hmmm, yeah, I hadn't thought about that all... I wonder if a N->M
plugin
could really support either of those? It seems like it couldn't, but
maybe I'm not thinking hard enough...
Well - it does get tricky, but the new version of the reverb will
support Bypass and it does this by essentially setting the wet/dry mix
to all dry... I think that actually gives you a nice implementation of
bypass as the effect is still in the chain doing some of the work it is
there to do (like 2->5) but its not actually adding its processing to
the audio... I think this is actually a strong reason to have bypass
implemented in the effect (you could imagine a similar implementation
of this in a delay for instance) - so instead of glitching as you flick
this switch, you actually here the tail fade... Apps can do some of
this themselves too of course if they want to remove the processing,
but fade the tail by using the Tail and Latency properties before
removing an effect from a chain...
I think its reasonable for an AU to not do inplace if it really can't -
and for eg. in the case of the reverb you could imagine that it would
or would not do in place processing based on the valence of its ins and
outs. It would also of course if it were to do this have to honour any
explicit settings of this property that a host had made. The main
problem here is if the host is doing buffer management, so its sets you
to NOT do inplace - then you really should not do it...
I guess the point I'm making is that there is flexibility that the AU
can apply to its interpretation of these properties.
Bill
Marc
--
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.