Re: AU-Newbie question re: parameters and Process()
Re: AU-Newbie question re: parameters and Process()
- Subject: Re: AU-Newbie question re: parameters and Process()
- From: Brian Willoughby <email@hidden>
- Date: Thu, 17 Apr 2008 17:27:54 -0700
On Apr 17, 2008, at 15:14, Howard Moon wrote:
I've been looking at various simple Audio Units examples, and
noticed that in the Process function, they call GetParameter to get
the current values of the parameters required for the audio
processing. In my work on other host platforms (e.g., VST), we've
kept the values used in processing as members of the "effect"
class. Then, when any parameter values were changed, we'd change
the corresponding member accordingly (sometimes mapping from the
given range to a range more suitable to our processing code).
This was a practice which may have begun in order to save precious
time when processing began, because we'd have all the processing
parameters already set and not have to go fetch them (and possibly
map them) at process time.
My question is: what's the standard method in the AU field? Do you
call GetParameter for all important values at processing time, or
do you store them in members (of the AUKernelBase-derived class),
so that they're right there where you need them?
My *guess* is that modern processors are fairly quick about this
sort of thing, and that calling GetParameter is not only plenty
fast enough, but also better practice, since it keeps the
parameters in one specific place, accessible via GetParameter at
any time.
Am I correct? Is it normal to call GetParameter to load up local
variables in the Process function?
Yes, it's normal. You can do it the other way, but then you'd have
to set up GetParameter() and SetParameter() to intercept the
settings. In either case, there is no mapping needed, since AU
parameters already have values in the appropriate range.
For the average AU, the SDK provides a dictionary that will
automatically hold any value described in GetParameterInfo(). You
even have some control over how the values are hashed, depending upon
whether you want fast access, versus the situation where you can't
guarantee that the parameter IDs are contiguous. The standard
implementation of GetParameter() and SetParameter() in the superclass
will access the dictionary for the value. So long as you avoid
accessing GetParameter() within your sample processing loop (e.g. so
long as you use local variables that can be allocated to registers as
needed), you probably won't notice any drag on the CPU.
However, you still have the option of using member variables for some
or all parameters. You just have to make sure that you properly
implement GetParameter() and SetParameter() to keep these values up-
to-date at all times. And you want to make sure you call the parent
class, especially if you leave some simple parameters in the standard
dictionary. I have had some cases where changing a parameter
required some expensive calculations that should only be done once.
Rather than write code to set a flag when these calculations are
needed, I simply handle it is SetParameter(), making sure that
everything else works as it did before. But it is quite rare to need
this, especially when your AU can describe which parameters depend
upon each other.
I think the general rule applies here: Don't optimize until you know
you need to. The standard AU parameter dictionary is probably fast
enough, and it even has a high-speed option if you're careful to keep
parameter IDs contiguous and make the API call to put it into fast
hash mode. If you still need optimization beyond those options, you
can still do it the old-school way.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden