Re: Parameters - Re: SDK Available
Re: Parameters - Re: SDK Available
- Subject: Re: Parameters - Re: SDK Available
- From: Urs Heckmann <email@hidden>
- Date: Sun, 4 May 2003 23:44:59 +0200
Am Sonntag, 04.05.03, um 17:45 Uhr (Europe/Berlin) schrieb Marc Poirier:
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...
To make B a generic type of thing in my plugin->AU wrapper, it'd be
cool to have C.
However, it's not in other formats as well, so I'm only a bit overly
picky about my favourite architecture 8-)
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. <snip>
Yeah, that's clear. But on every event stuff and his auntie you can add
your own private data structures. You usually put in a "this" so your
handler gets that to know whom to address for processing.
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.)
It's no big deal. You are used to that from other Carbon APIs.
* Are the things that you want to do really private/internal tasks that
don't belong in the public API?
I think they are application specific.
* Are the things that you want to do useful to others in general and
therefore should be added?
Hmm, don't think so. This is just my private way of doing some things.
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.
Hmm. Well, I one could start a little thread like this:
"Which are typical parameter-bound tasks/features that might be handy
to have as metadata?"
The thing I fear is that everybody has different views to this, but who
knows 8-)
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.
Well, I don't think it's for listeners in general, it's for the
simplification of parameter handling inside the plugin classes (dsp +
ui).
One may argue differently, but I'd find it more elegant to have a
single place where my parameter stuff resides than having two seperate
regions, one for the formalities and one for the chemical apparatus.
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...
Well, it's even more offensive 8-)
Some of the data I'd like to attach would just be addressing my
laziness to change source code at different places in different files.
I want to have a single place, for instance in the long run to build up
whole plugin architectures from an XML file or a construction kit.
Dunno.
Anyway, I'm still not very clear on the specifics of what you need with
your plugins,
I'm trying to simplify some things.
The "smooth" stuff is about interpolation of parameters that usually
cause jitter or clicks when the user changes them. Like most "volume"
knobs out there. I'd like to set up lowpass coefficients according to
the individual smoothness a parameter needs.
Some other "hints" would be "change + precalculate immediately (Thread
unaware)" vs. "change on next render call (needs thread awareness)" or
"concerns multiple voices".
For the UI, I'd like to add some stuff that gives some hints for
control factories, to make generic approaches more flexible.
Could be, in the end there'd be some semantics or inter-parameter
relations. Well, sci-fi.
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.
Well, it doesn't have to be there. A small voidy pointer or structure
would be helpful though. It'd let me keep things together in one place.
If that's only good for me, just forget about it 8-)
Cheers,
;) Urs
_______________________________________________
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.