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: William Stewart <email@hidden>
- Date: Mon, 29 Jan 2007 11:55:33 -0800
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
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)
Obviously, I could just say I support 8 channels max and that
solves #1 but I haven't come up with a good solution for #2. Any
ideas?
It is my current impression that you can only connect audio units
with matching formats so you couldn't do something like connect an
AUSampleDelay to just the "left surround" channel of an output unit
set for 6-channel output. Correct? Since AUSampleDelay applies
the same delay to all of its channels, that's why I'm writing this
unit in the first place.
Yes - the connection format between two AUs must be shared
Bill
thanks,
stephen
P.S. The SDK base classes and overall infrastructure are awesome,
I've written 3 effects in no time at all -- very cool.
P.P.S. The comment about N-to-M effects not being supported very
well in AUEffectBase.cpp is true. Please fix it. :-P
_______________________________________________
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
--
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
________________________________________________________________________
__
_______________________________________________
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