AU->View communication
AU->View communication
- Subject: AU->View communication
- From: "Russell ." <email@hidden>
- Date: Thu, 7 Jul 2005 11:56:39 +1000
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?
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.
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.
CAUGui, in its "internal parameters" stuff, therefore just polls them
in the GUI's idle timer. 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?
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