Re: Parameters - Re: SDK Available
Re: Parameters - Re: SDK Available
- Subject: Re: Parameters - Re: SDK Available
- From: Marc Poirier <email@hidden>
- Date: Sun, 4 May 2003 17:45:32 +0200 (CEST)
>
> But actually my primary reaction to this suggestion of yours is: how
>
> specifically are you having problems with the current parameter data
>
> that require you to use dual representations of parameters?
>
>
Well, as you know or might guess, I'm now following some sort of
>
generic approach in my modular audio objects engine (or whatever to
>
call it, if not "my plugins wrapper" 8-).
>
>
Now, to keep it generic, I need to make some sort of list where for
>
each parameter I need:
>
>
a) all the AUParameter fields (that come in very handy)
>
b) references to objects that listen to each parameter (oh, btw, those
>
are groups!)
>
c) my personal parameter hints: Smooth user changes or not and how much
A is taken care of already. For B, you can install parameter listeners,
which AUBase will take care of managing for you. For C, I can't think of
any place that fits in to the existing API...
>
> Adding opaque data
>
> chunks to parameter metadata could be considered sort of a hack, and at
>
> least a last resort, so I think that talking about adding such a
>
> feature is really jumping past the real issue that needs to be
>
> discussed which is: why are you finding yourself using dual
>
> representations of parameter values? There might be a much better way
>
> to solve your problems than with opaque data blocks for parameters,
>
>
Opaque data structures are used all over Carbon (Uhm, and my GUI stuff
>
as well). I see them as means for customization.
Well, that's pretty different. Those are not private, variable-size,
opaque data chunks. They are defined data structures for defined system
APIs. They contain data that is publicly accessible to all folks using
the APIs, but only accessible via accessor methods. This is simply for
reasons of good API design. In order to prevent anyone from writing code
that makes assumptions about the data structures, which are subject to
change and therefore might fail or cause very bad behavior in the future
with legacy code that makes these assumptions, instead Apple writes the
only code that directly deals with the data structures (the accessors) and
then we use those accessors, safe in our knowledge that that will allow
our code to work down the line (or at least fail nicely with an error
return), even if those data structures change. But the basic issue is
that this is public, defined, standardized data in those structures for an
API, albeit opaque, but not private, variable-size, opaque data
structures.
But I don't mean to say that private opaque data structures are a terrible
thing, I'm just saying that they should be questioned in a number of ways
before considering adding them to any part of a public API, like:
* Is there a way to do what you want neatly with the current API? (You
don't want to add mess to an API when unecessary, it just makes it harder
to learn and understand.)
* Are the things that you want to do really private/internal tasks that
don't belong in the public API?
* Are the things that you want to do useful to others in general and
therefore should be added?
For that last one, for example with your smoothness value things, maybe
that extra you're metadata you're storing is actually generally useful to
more developers than just yourself (I must admit, I don't really
understand what you're talking about with that, so I'm not sure), in which
case it would be way better to add a smooth/smoothness value to
AudioUnitParameterInfo rather than a private data chunk.
Also I think that, with respect to the second question in my list, you
want to think about which of these data bits need to be available to
listeners (the UI, host, generic interfaces, etc.). Like I said, I'm not
totally sure what you mean by these smoothness attributes, but I'm
wondering whether they are anything that your listeners even need to know
about. If you're just talking about data that only your audio component
needs internally, then I don't see why you need to incorporate it into the
ParameterInfo via the standard API mechanisms. Just store it however you
want internally in your audio component. It only matters when you need to
share this info with external listeners.
Also, maybe it's the case that only your custom UI will need the data but
not any other listeners. In that case, maybe the best and cleanest way to
do this would not be to mussy up the AU API but to use custom private
properties to share the data and then store the data in the ControlData
for your custom UI's controls. Or something like that, again, I'm not
really sure about your specifics...
Anyway, I'm still not very clear on the specifics of what you need with
your plugins, but I'm really just trying to bring up questions that I
think need to be answered before talking about API implementation issues
like adding stuff to AudioUnitParameterInfo.
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.