AU parameter groups proposal
AU parameter groups proposal
- Subject: AU parameter groups proposal
- From: Marc Poirier <email@hidden>
- Date: Tue, 10 Jun 2003 15:06:48 -0500 (CDT)
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.
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).
Consider an AU that has 15 LFOs, and each LFO has a common group of
parameters to control it: rate, synced rate, depth, shape, and tempo
sync. If we could define parameter groups, then each could be in its own
group, and instead of seeing a list of 75 parameters, you would see a list
of 15 groups (LFO 1, LFO 2, etc.) as submenus, and within each submenu you
would see the 5 LFO controls (rate, shape, depth, sync, and synced rate).
Anyway, I'm just trying to illustrate how, in practice, this feature could
improve usability of music software and solve a problem that clearly
exists already.
Okay, now my implementation idea...
I think that all you'd need to do is to add a new member to the
AudioUnitParameterInfo struct, something like this:
typedef struct AudioUnitParameterInfo
{
#if TARGET_API_MAC_OSX
char name[60];
CFStringRef cfNameString;
#else
char name[64];
#endif
AudioUnitParameterUnit unit;
Float32 minValue;
Float32 maxValue;
Float32 defaultValue;
UInt32 flags;
SInt32 groupID;
} AudioUnitParameterInfo;
Then you add a new property kAudioUnitProperty_ParameterGroups. This can
function exactly the same as FactoryPresets, pretty much. The AU can
return a list of a struct that would look just like the AUPreset:
typedef struct AUParameterGroup {
SInt32 groupID;
CFStringRef groupName;
} AUParameterGroup;
Everything about getting this list can be handled just like the
FactoryPresets property is handled, I think (or maybe like the
SupportedNumChannels property is handled).
So then, when you handle GetParameterInfo, you will want to do something
with info.groupID if you want to indicate that a parameter belongs to a
group. You simply store the ID number in that value. If the paramter is
not in a group, then you make that zero. There could be a constant
defined in AudioUnitProperties.h kAudioUnitParameterGroup_NoGroup=0 or
something like that to specify this.
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?
Thanks for listening,
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.