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: William Stewart <email@hidden>
- Date: Fri, 30 Jan 2004 14:28:18 -0800
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
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...
Cheers,
;) Urs
urs heckmann
email@hidden
www.u-he.com <- Zebra Audio Unit
_______________________________________________
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
________________________________________________________________________
__
--
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.