Re: AU parameter groups proposal
Re: AU parameter groups proposal
- Subject: Re: AU parameter groups proposal
- From: Marc Poirier <email@hidden>
- Date: Wed, 11 Jun 2003 14:32:58 -0500 (CDT)
Hi Airy.
On Wed, 11 Jun 2003, [ISO-8859-1] Airy Andri wrote:
>
To preserve compatibility, I first thought taking the problem the other
>
way : don't change anything from what has already been defined, and add
>
new properties for new features.
>
>
- don't change the AUParamInfo structure, so you are sure you don't
>
break anything.
>
(Where the "inDataSize" come from ? You don't have it right now (at
>
least with my version of AUBase::DispatchGetProperty).
>
Your trick should be moved to AUBase::ComponentEntryDispatch, which
>
currently ignore inDataSize and use the info from GetPropertyInfo.
>
But I agree this can be easily done, while I am not sure I totally
>
like it)
Oh you're right, I was thinking of DispatchSetProperty with the dataSize
argument. However, now that I looked into this more, I see that
AUBase::ComponentEntryDispatch already does "my trick" ;) exactly as is
needed (that's the method that is hit before Dispatch*Property). So in
fact my proposal could have been simpler than it was and still work
without breaking any backwards or forwards compatibility, and it also
means that plugins don't need an updated SDK to work correctly, either,
the SDK base classes as they are now handle this sort of situation
perfectly. Or in other words, my example code for
AUBase::DispatchGetProperty was unnecessary; the current implementation
needs no modification to work with an extended ParameterInfo.
>
- add a property "GetGroup", which would return the groups defined.
>
A group would have at least a "name", and the list of its parameters.
I think that having the GetGroups property have to return a variable sized
list of items that themselves are lists of variable size is not as simple
as could be and trickier to implement on the plugin-side (easier to make
mistakes).
>
Or we could also add an "parameter extented infos" structure, which
>
could have all the things you want to add to parameters like the group
>
ID, and a property GetParameterExtentedInfo to get them.
>
Maybe we could have some public infos in it, like the Group ID, as well
>
as some private one (like additionnal infos for the parameter type, or
>
your default value ? ;-).
>
It could help in not duplicating the public and private parameters info
>
in several structures, which is always prone to error when
>
adding/changing/reordering parameters.
>
Keeping some place for future extension would also propably be a good
>
idea.
I like this idea better, but I think, given what I've just looked at, that
the current ParameterInfo is even more safely extensible than I previously
thought. So if it's possible to avoid making a GetParameterInfoPart2, I
personally think that that would be preferable...
>
The problem being to first keep everything clean, easy to
>
read/write/understand, extensible and compatible...
I totally agree, but I think that luckily we have that already and can
safely extend ParameterInfo with no compatibility problems as a result.
Or am I missing something? It seems that way to me, now that I've looked
more carefully at AUBase::ComponentEntryDispatch...
Thanks,
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.