RE: How to handle "mode" parameters that fix the value of other parameters?
RE: How to handle "mode" parameters that fix the value of other parameters?
- Subject: RE: How to handle "mode" parameters that fix the value of other parameters?
- From: Steven Clark <email@hidden>
- Date: Fri, 30 May 2014 18:06:58 +0000
- Thread-topic: How to handle "mode" parameters that fix the value of other parameters?
I can't speak directly to what auval accepts or rejects.
Your current design (as you briefly described) has some mild ambiguity. What does it mean for the client to change these parameters when the unit is in one of the "fixed" modes? What should happen if the client changes XXXX while in a "fixed" mode, and then switches to the adjustable mode - should the value of XXXX jump to the value the client recently set, or should it remain at the value it had in the previous mode?
If you reject or ignore changes when in the fixed modes, that is likely to confuse auval and might confuse whoever is writing your client software. Still, it is a clean design if the semantics are what you want.
An alternative is to have two parameters each for XXXX and YYYY, perhaps XXXX-current and XXXX-adjustable (and the same for YYYY). XXXX-current is readonly and tells the client whatever the current value is that's being used, whether you're in the adjustable mode or not. XXXX-adjustable is writable and is the setting of XXXX to be used when you're in the "adjustable" mode. This design avoids what confuses auval.
In any case, this is a potentially confusing part of your interface for developers of client code, so I hope you can document it well.
Steven J. Clark
VGo Communications
-----Original Message-----
From: coreaudio-api-bounces+steven.clark=email@hidden [mailto:coreaudio-api-bounces+steven.clark=email@hidden] On Behalf Of B.J. Buchalter
Sent: Friday, May 30, 2014 12:55 PM
To: CoreAudio API
Subject: How to handle "mode" parameters that fix the value of other parameters?
Hi Folks,
We have an AU we are working on that is currently failing auval in the "retain value across reset and initialization":
> Testing that parameters retain value across reset and initialization
> ParameterID=XXXX, Scope=0, Element=0: Saved Value = 4587.036133,
> Current Value 500.000000 ParameterID=YYYY, Scope=0, Element=0: Saved
> Value = 433.105469, Current Value 500.000000
> ERROR: Parameter did not retain set value when Initialized
These parameters are affected by a different "mode" parameter. The "mode" parameter is declared as global meta, and these parameters are dependent on it. When the mode parameter is set to a specific value, then these parameters are free to be set by the user. But if the mode parameter is any other value, it controls the values of these parameters and they cannot be changed by the user.
auval does not seem to check for the dependent parameters property during its testing.
So, the problem appears to be that auval does the following:
Sets the values of XXXX and YYYY
Resets the AU
Initializes the AU
Checks the values of XXXX and YYYY
At the Initialize phase, the AU re-sets the values of XXXX and YYYY based upon the value of the mode parameter.
Should I be rejecting changes to XXXX and YYYY when the mode has them fixed? Will that work, or cause a different auval failure?
How should I be handling this so that the plugin passes (1) auval, and (2) continues to work as expected.
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
_______________________________________________
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
_______________________________________________
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