Re: n-chan effect with per-channel params question
Re: n-chan effect with per-channel params question
- Subject: Re: n-chan effect with per-channel params question
- From: Stephen Davis <email@hidden>
- Date: Tue, 30 Jan 2007 11:37:41 -0800
On Jan 29, 2007, at 11:55 AM, William Stewart wrote:
On 26/01/2007, at 1:21 PM, Stephen Davis wrote:
I'm working on a "speaker time alignment" effect unit which just
implements per-channel delay but supports a different sample delay
parameter per channel and I have a couple of questions:
1) To support generic indexed parameters (delay1, delay2, etc.) I
have to know how many params I have before anyone queries me so
the number of indexed parameters is usually (per the sample code)
set up in the constructor. At this point, I don't know how many
channels I'm going to have and the stream format can change so
that will break things. Can I reconfigure my number of indexed
parameters at any point? That seems like it would confuse the
heck out of any host who's creating a generic view for my AU.
Yes - we have the same problem to solve with various AUs that meter
(compressors and limiters) where the number of meters we publish
depends on the I/O formats.
By default, an effect unit does not allow a format to be changed
when it is initialised, so the AUs we have calculate the number of
parameters it needs based on the num channels in the Initialise
call, sets all of that up so that it can fulfil the requests for
information about the parameters, etc, and then does this (at the
end of the Initialise call):
if (mLastInitChannelNum != nchannels) {
mLastInitChannelNum = nchannels;
PropertyChanged (kAudioUnitProperty_ParameterList,
kAudioUnitScope_Global, 0);
}
Views are required to have property listeners for at least this
property (as our generic views do) and we then respond to this by
restructuring the view
That's a good point and easy enough to do.
2) Since I have per-channel delay values, what is the *right* way
to match the current processing kernel in its Process() routine to
its channel delay? I could override SetParameter() and pass the
value into the kernel at that time but that wouldn't let me take
advantage of scheduled parameter updates that AUEffectsBase
handles for me.
I think this is true - but its worth checking!!!
If you just have your kernel call SetParameter in its process
method, the intention was that it would give you back the current
value of the parameter. AUBase will split up the processing into
block if there are intra-buffer scheduled parameters (and it should
also ensure that GetParameter called at that time will return you
that value).
You could check this out with auval - it has a test at the end
where it schedules intra-buffer parameters (and ramps if there's a
param marked with kAudioUnitParameterFlag_CanRamp)
Actually, if I do the suggestion above, I can just tell each kernel
"use parameter index N" at the end of the Initialize() call and then
it uses that index in its Process() method. Since the mKernelList
vector won't change order after initialization, that order is the
parameter index and channel order I want. Duh. :-)
Thanks!
stephen
_______________________________________________
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