Re: PostConstructor vs Initialize (AU's built-in Parameter Implementation)
Re: PostConstructor vs Initialize (AU's built-in Parameter Implementation)
- Subject: Re: PostConstructor vs Initialize (AU's built-in Parameter Implementation)
- From: yoshida <email@hidden>
- Date: Mon, 2 Feb 2004 11:01:57 +0900
Hi, I'm original poster.
This discussion is very helpful for me!
Thanks for the info, Usr and Bill.
At 2:28 PM -0800 04.1.30, William Stewart wrote:
Urs,
You're quite correct and I'm glad you added this observation...
On 29/01/2004, at 4:40 PM, Urs Heckmann wrote:
Am Donnerstag, 29.01.04 um 20:34 Uhr schrieb William Stewart:
To my mind this is a far better mechanism, as it also
avoids you having to both:
(a) write a parameter mechanism yourself (even if that is something as
simple as member variables in your AU class)
(b) Having done (a), you'd also then need to over-write the
Save/Restore methods of AUBase to save and restore your parameter
variables to/from an AUPreset dictionary.
The supposed optimisation of (a) above I think can best be
characterised by the observation "Premature optimisation is the root of
all evil" :)
Hehe, evil calling here 8-))
How would you change some complex, rarely changing internal states
(i.e. filter coefficient calculation or getting callbacks for the
correct oscillator module, whatever) outside Render() then? - To be
precise, if one doesn't overwrite SetParameter(), the first time
the AU becomes aware of a parameter change is upon render call,
right? (Please correct me if I'm wrong...)
In the case you're desribing this is indeed the reason why
SetParameter is a virtual method so that it can be over-written.
ie. where some complex state has to be generated from the change in
a parameter's value and that is better done when that value
changes, rather than every time you're rendering.
One problem with this approach though, is that that then quantifies
the parameter's value to a buffer boundary. Maybe not a problem if
you are rendering small buffers, but if you're rendering large
slices (which is common when you are in an offline situation)
unless your implementation can take of multiple values within the
next render cycle... In some cases this is a reasonable trade off,
and a decision you need to make on a case by case basis.
Bill
--
-----------------------------------------
English is not my native language,
so I'm not good at English, sorry :-(
M.Yoshida @ Japan
_______________________________________________
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.