Re: Parameters - Re: SDK Available
Re: Parameters - Re: SDK Available
- Subject: Re: Parameters - Re: SDK Available
- From: Marc Poirier <email@hidden>
- Date: Mon, 5 May 2003 05:16:41 +0200 (CEST)
>
> 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.
Oh I see, I misunderstood what you were referring to...
>
> 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-)
>
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).
The UI is a listener. Considering the DSP and UI to both be "inside the
plugin" breaks the AU model, where UI and DSP are actually separate
plugins. Anyway, just clarfying what I meant by "listeners"... So if
you're talking about stuff that the UI and DSP need to share, then that
qualifies as what I meant by "public" data.
>
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-)
I just thought it would be good to go through some preliminary issues of
what you were doing first. :) So it sounds like your needs are, as you
say, pretty application specific and need to be shared between audio
component and listener (UI). I still wonder whether simply private
properties wouldn't suit your needs (define a custom property ID and query
it with the parameter number is the element argument), since pointers
between DSP and GUI component, unless also specifying data size, wouldn't
be good; but once you start doing that it looks more like AU properties
anyway, but I don't know, maybe I'm overthinking this... But mostly I had
questions that I thought ought to be answered, which now have been...
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.