Re: Paremeter changes by the user
Re: Paremeter changes by the user
- Subject: Re: Paremeter changes by the user
- From: William Stewart <email@hidden>
- Date: Fri, 18 Jun 2004 14:40:42 -0700
Also
AUEffectBase has support for splicing your Render call's buffer up into
segments based on parameter calls that schedule parameter values at a
sample offset - if you use the kernel's for doing your processing then
this all just kind of works -
//
________________________________________________________________________
____
//
// This method is called (potentially repeatedly) by
ProcessForScheduledParams()
// in order to perform the actual DSP required for this portion of the
entire buffer
// being processed. The entire buffer can be divided up into smaller
"slices"
// according to the timestamps on the scheduled parameters...
//
ComponentResult AUEffectBase::ProcessScheduledSlice( void
*inUserData,
(This turns around and calls ProcessBuffers, which turns around and
calls each of the processing kernels to process some number of samples
which maybe a part of your render buffer's total numFrames if there are
scheduled parameter changes)
Then - in your Process call (in the Kernel) - you call through to the
(typically Global's Element to get the parameter values FOR THAT SLICE
- AUBase sets this up for you as part of this mechanism...
There are two calls on the Element object that are of interest -
depends on whether you've published that a parameter is rampable (which
we strongly recommend that developers support) or not... If not then:
Float32 GetParameter(AudioUnitParameterID paramID);
If rampable then always call this one:
// interpolates the start and end values corresponding to the current
processing slice
// most ramp parameter implementations will want to use this method
/*! @method GetRampSliceStartEnd */
void GetRampSliceStartEnd( AudioUnitParameterID paramID,
Float32 &outStartValue,
Float32 &outEndValue,
Float32 &outValuePerFrameDelta );
In the case where a rampable parameter is jsut being set to a given
value, Start and End value will be the same...
Bill
On 18/06/2004, at 1:28 PM, Marc Poirier wrote:
>
On Fri, 18 Jun 2004, Aristotel Digenis wrote:
>
>
> Thank you Brian and Bill,
>
>
>
> Good point, about calling the GetParameter function in the rendering
>
> and
>
> therefore having the latest value on a per sample basis. However I
>
> have
>
> chosen to go with the SetParameter when a slider is changed because I
>
> will actually be doing some calculations on that incoming parameter
>
> before its use in the render stage. I was also a bit confused with the
>
> two SetParameter functions, one that takes 2 arguements and one that
>
> takes more. I now have it working just fine.
>
>
That's C++ function overloading.
>
>
> Out of curiosity, calling the GetParameter function for the parameter
>
> on
>
> every sample would take more processing power than having the value
>
> set
>
> only when the slider is moved?
>
>
Well, it's not really just a choice between those 2 options. If you're
>
worried about calling GetParameter for every sample, then why not just
>
call GetParameter once at the start of your rendering and then store
>
the
>
result in some local variable in your render function? Just like what
>
I
>
am guessing your were doing in your SetParameter overriding approach
>
(though I guess a class variable not a local one), right?
>
>
Then there's also this to think about: if you are doing much in the
>
way
>
of calculations in response to some parameter changes, and given that
>
you
>
may get many SetParameter calls for one render slice, then do you want
>
to
>
be doing your calculations in SetParameter, possibly several redundant
>
times, rather than doing them once at the start of your rendering? Or
>
if
>
your calculations are really very heavy, and you want to make sure that
>
you really only do them when absolutely necessary and only when the
>
parameter has definitely changed, and not multiple times for one slice
>
if
>
the parameter changes multiple times, then maybe you want a different
>
approach where you set a flag of some sort in SetParameter, then check
>
the
>
flag in render and do your calculations there if something changed.
>
>
Anyway, at that point it all just really depends on the specifics of
>
your
>
plugin. But if you want the easiest way, then call GetParameter during
>
render. If you have unique performance concerns, then think about all
>
the
>
options and what is best for your application.
>
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.