Re: Understanding Parameter Handling & Constraints using a custom UI
Re: Understanding Parameter Handling & Constraints using a custom UI
- Subject: Re: Understanding Parameter Handling & Constraints using a custom UI
- From: Brian Willoughby <email@hidden>
- Date: Thu, 13 Jan 2011 18:04:37 -0800
I believe that CoreAudio has left some of this vague in order to
maximize flexibility.
In my experience, there are often instances where it makes sense to
publish a somewhat narrow range for the official parameter, so that
Generic UI elements have a sensible resolution, but to unofficially
allow a much larger range. e.g. The threshold for a gate probably
isn't useful to 90% of the users below about -48 dB, so it would make
sense to publish a threshold range of -48.0 to 0.0 in decibels.
However, manually-entered values all the way down to -144 dB might be
useful in certain situations.
In light of this, I would say that it is the responsibility of the
AudioUnit to clamp parameter values to the range that it can handle,
without depending upon outsiders to always honor the published range
limitations.
So, attempting to answer your questions, I would say that you do not
necessarily need to take care that your custom UI does not make it
possible to enter values outside of the published range. Instead, I
would say that your AudioUnit engine must take care to react properly
to any input value, even if that value is outside the published range.
As for automation, I'm not sure what would be proper. I have not yet
actually implemented the example gate threshold with a published
range of -48 to 0 dB that still accepts any threshold except NaN.
So, I can't say whether host applications would properly handle void
ranges, especially considering my opinion that values outside the
published range are not necessarily void.
Brian Willoughby
Sound Consulting
On Jan 13, 2011, at 16:22, Stefan Huber wrote:
If I use a generic UI, everything seems pretty clear. I set the min
and max values (etc.) and use the GetParameterInfo() method to
"tell" the Host their properties. The generic UI is limited to
these values.
If I use a custom UI, there is no limit in first place. So I would
need to take care, that I am not able to enter values, that are not
in range using the custom UI? For the automation, the Host knows
the range of the parameters by querying GetParameterInfo(). If I
limit the parameters within the UI, and the Host limits the
parameters according to the defined range, I shouldn't need to
check the range of my parameters within the Audio Unit anymore. Is
this correct or is there a better way?
Does this mean, I need to create a listener in the AU for every
parameter that I need to check against another? Every time the
constraint is violated I would report the correct value back using
a AudioUnitSetParameter() call? When dealing with automation I
would need to have a listener in the UI for every parameter that
might be automated as well, so that changes to the parameters will
be visible in the UI. However, cases like manually drawn automation
data wouldn't be prevented to be drawn in void ranges. Is this all
how it is meant to work or did I get something completely wrong.
Dealing with a custom UI seems pretty complicated in the beginning.
_______________________________________________
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