Re: AU parameter groups proposal
Re: AU parameter groups proposal
- Subject: Re: AU parameter groups proposal
- From: Airy André <email@hidden>
- Date: Wed, 11 Jun 2003 21:02:55 +0200
Le mardi, 10 juin 2003, ` 22:06 Europe/Paris, Marc Poirier a icrit :
As has been mentioned before, some folks think that it would be great
if
AUs could define parameter groups for their parameters. I agree, and I
just thought of a possibly good way to implement it.
I agree.
First I'll try to illustrate why this would be such a nice extension of
the AU API:
Think about Logic's automation parameters menu, for example. If you
look
with a plugin that has tons of parameters, it's a nightmare (well,
part of
that is because the list is alphabetized, but that's another issue).
I still agree.
...
So I think that this could be a good implementation for a couple of
reasons: 1) it's simple to do it and get it right and 2) it could be
added while still preserving backwards compatibility. When a host gets
the ParameterInfo property, you just need to check the dataSize
argument
and only memcpy as much of the AU's output data as the host has made
available, so that if the host is still using old headers, then the
groupID value simply is omitted (just like how the HostCallBacks
property
is handled). Something like this in AUBase::DispatchGetProperty:
case kAudioUnitProperty_ParameterInfo:
{
AudioUnitParameterInfo paraminfo;
bzero(¶minfo, sizeof(paraminfo));
UInt32 availSize = (inDataSize < sizeof(paraminfo) ? inDataSize :
sizeof(paraminfo));
result = GetParameterInfo(inScope, inElement, paraminfo);
if (result == noErr)
memcpy(outData, ¶minfo, availSize);
}
break;
So that's my idea for how to add this feature. What do others think?
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)
- add a property "GetGroup", which would return the groups defined.
A group would have at least a "name", and the list of its parameters.
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.
The problem being to first keep everything clean, easy to
read/write/understand, extensible and compatible...
Just a (too ?) quick thought.
Airy
_______________________________________________
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.