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: Marc Poirier <email@hidden>
- Date: Sun, 1 Feb 2004 14:23:06 -0600 (CST)
On Fri, 30 Jan 2004, 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...)
>
>
If your implementation is only aware of parameter changes when
>
rendering, you end up with a lot of if( parameter_x !=
>
parameter_x_as_of_last_time ){ // do expensive stuff; } at the
>
beginning of each render call (can be costy even if branches are not
>
taken), or, if you install a ParameterListener (which would be even
>
more evil due to possible synchronisation problems), you could as well
>
overwrite...
>
>
Doesn't necessarily have to be this way, but in my 500+ parameter
>
monsters it is... 8-))
>
>
Wouldn't an implementation like this be un-evil enough:
>
>
ComponentResult myFunnyAU::SetParameter(AudioUnitParameterID inParamID,
>
AudioUnitScope iScope, AudioUnitElement iElem, Float32 rValue, UInt32
>
iSchedule)
>
{
>
// Search for special cases
>
if (iScope==kAudioUnitScope_Global && iElem==0)
>
{
>
switch ( inParamID )
>
{
>
case mySeriousCalculationParam1: doThatStuff1(); break;
>
case mySeriousCalculationParam 2: doThatStuff2(); break;
>
case mySeriousCalculationParam 3: doThatStuff3(); break;
>
...
>
case mySeriousCalculationParamN: doThatStuffN(); break;
>
}
>
}
>
return AUBase::SetParameter( inParamID, iScope, iElem, rValue,
>
iSchedule);
>
}
>
>
... still better than having to do serious calculation each render
>
call, or N if()s...
Not necessarily, it really depends. It depends on: 1) how serious the
state changes are, 2) whether you're willing to lose sample-accurate
time-stamping of parameter changes, and 3) how dense parameter changes are
in a certain scenario, which will change from day to day for user to user.
For an example of 3, what if the user is moving a control around a lot
really quickly and generating 30 parameter value changes for a single
parameter in a single render slice. If you do your way, you will be doing
the heavy calculations 29 times needlessly, and not even getting the
benefit of sample-accuracy, because your approach also takes away the
possibility of sample-accurate parameter changes.
Also, a bunch of if()s done *once* in a render call really is not bad at
all usually (the evilness of branches is highly overrated, in my opinion,
and in my benchmarking), it's more if you're doing those per-parameter and
*per-sample* in the render call that you would need to worry, probably.
But anyway, as always, you can't make hard and fast rules about this, you
need to think about the needs of your specific application and the
trade-offs of the different approaches, and then always benchmark, there
aren't "speed priniciples" that you can rely on in this sort of case, you
need to benchmark to know.
Marc
_______________________________________________
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.