Re: AU->View communication
Re: AU->View communication
- Subject: Re: AU->View communication
- From: William Stewart <email@hidden>
- Date: Thu, 7 Jul 2005 10:53:19 -0700
On 06/07/2005, at 6:56 PM, Russell . wrote:
Hello,
I am after a bit of newbie help... I'm sure what I'm about to ask
would be a FAQ so perhaps the answers could be placed on the wiki
site.
My question is, what are the recommended means of communicating
information from the audio unit to the view?
I found various discussion on the list archive about "private
parameters". I presume these are simply parameters that have an ID
number not included in the list returned by GetParameterList() ? And I
assume that even though they are not included in that list, one can
still install a Listener for them in the GUI, and Notify it from the
audiounit?
What about parameters that are in the "published" list, but are read
or write only? (and what is the meaning of this, readable and writable
by whom?) Can they be used for a similar purpose?
Think of a boolean parameter:
Read only - "signal light"
Write only - "push button"
read.write - "check box"
Other parameters that are read only might be used for metering (see
Apple's AUMultibandCompressor).Read only that are not meters may also
be used just to supply a textual value (lets say a tempo indicator).
We also introduced a new parameter flag in Tiger (and Panther with QT
7) - kAudioUnitParameterFlag_MeterReadOnly - to indicate that a read
only parameter is a meter, and should thus have a different UI
behaviour than a textual read only param.
All of these features of parameters are supported with Apple's
Generic cocoa view (CoreAudioKit/AUGenericView.h) - this view is also
used in the AU Lab application if you want to see it in action.
What about other means of doing it? The private parameter approach
would become rather tedious when dealing e.g. with multi-element
"parameters" (as I am) or arrays. Also I worry it might be a very slow
way to do it, sending separate messages for dozens or hundreds of
parameters, 10 times a second or so. It is also a bit kludgey the way
you need to make your GUI only re-draw when it receives notification
the "last" parameter to change in a set of related parameters, as it
involves knowledge of what order the audiounit chooses to send the
notifications in. One could make a special fake "redraw" parameter but
this again would be fairly kludgey.
At WWDC this year we dealt with this issue with an example AUFilter -
it drew a response curve for the user. A private property was used to
retrieve the filter's frequency response; the view then drew this.
This is implemented by passing data using a private property. We will
have this example in the SDK when we next release it (shortly). Oh,
we also strongly discourage the passing of pointers using this
approach and encourage you to view the AU and its view as separate
objects - think of them as if they were running in different address
spaces.
An alternative I have seen little references to seems to be to use
properties. But apparently you shouldn't send property change
notifications from the audio thread as they might block for too long.
No. You can use the AUEventListener notification mechanism with
properties just as you can with parameters; this is a non-blocking
notification. A view which *listens* to private property changes
should also use this mechanism so that it ensures that its
notification occurs on the main thread. Thus, this becomes a
"render process" safe mechanism.
This was also covered at the WWDC session this year, and in the
implementation of the AUFilter.
CAUGui, in its "internal parameters" stuff, therefore just polls them
in the GUI's idle timer.
Yes, that is a very bad approach and one we would discourage - the
exception to this is a metered, read-only parameter which by its
nature needs to be drawn on a regular basis.
Again this makes my hair stand on end a
little ;). I guess you could use a fake private parameter to notify
the gui on when to re-fetch a given property. Is this an acceptable
approach? Again it strikes me as a bit ugly but perhaps it is the
least ugly way? (ideal would be a kind of non-blocking property
change notification call)
Finally, a completely unrelated and basic question : coreaudio
supports a variety of different stream formats right? And yet, all the
example audio effect units I've looked at assume that the buffers are
32-bit native float PCM streams, without checking. Is this actually a
safe assumption?
They certainly do not assume that - have a look at the implementation
of SetProperty for the StreamFormat
Bill
that will do for now :)
these seem like rtfm questions but am I right in assuming there is no
fm to speak of?
thanks
Russell
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden