Re: AudioUnit : how to communicate from DSP to GUI ?
Re: AudioUnit : how to communicate from DSP to GUI ?
- Subject: Re: AudioUnit : how to communicate from DSP to GUI ?
- From: Chris Rogers <email@hidden>
- Date: Mon, 14 Oct 2002 12:00:53 -0700
Benjamin,
It should be possible to implement a private parameter by simply not
publishing its existence in the GetParameterInfo() virtual method.
It also is probably necessary to override GetParameterList() to not
report these. We may want to provide explicit support for this in our
base classes, but it's not too difficult to add this yourself.
Our APIs such as AUParameterListenerNotify() in
AudioToolbox/AudioUnitUtilities.h provide a service for avoiding the
type
of polling you're talking about.
This would require the AudioUnit to call AUParameterSet(), and so
a AUParameterListenerRef would have to be given to the AudioUnit
(via a private property for example). This is all doable, and Doug
may have some further comments about how he would consider handling
this case.
You bring up some good points. We probably should reflect upon this
a bit further and keep up the discussion...
Chris
>
well...... I'm sorry to have used this "hack". After all, i'm not
>
really proud of it and I'd like to find something better.
>
>
The main question then is : is it possible to have a private api
>
between a view and an audiounit based on parameters, but do NOT
>
allow to display those parameters in a host "generic" view ? (even
>
in "advanced" mode (i've seen this flag in the param infos) )
>
>
On the other hand, having properties in the audiounit (that the view
>
continuously reads) means polling must be used for every visual
>
attribute, right ? What if we want to display a virtual key being
>
pressed when the audio unit receives a "note on" event ? Is there an
>
easy way to solve this using a read-only protocol ? Maybe use
>
properties on the view side, too ?
>
>
Benjamin Golinvaux
>
Arboretum Systems, Inc.
>
www.arboretum.com
>
>
>
>
On Sunday, October 13, 2002, at 02:38 AM, Chris Rogers wrote:
>
>
>These vu-meters, clipping LED, etc. should all be reported as read-only
>
>parameters accessible via the ordinary property APIs for AudioUnits.
>
>The internal DSP of the AudioUnit may set these parameters in real-time
>
>for the UI to display. What we want to avoid is people adding extra
>
>hacks like accessing C++ objects directly or adding C APIs.
>
>If there's something we've neglected in the standard APIs, then lets
>
>address the issue cleanly.
>
>
>
>Chris Rogers
>
>Core Audio
>
>Apple Computer
>
>
>
>>>Hmmm...
>
>>>
>
>>>We'll, I'd be careful here. [...]
>
>>
>
>>The situation that I describe is a reality. Great numbers of
>
>>existing market plugins provides vu-meters, clipping led, that are
>
>>computed to a particular stage of dsp processing.
>
>>
>
>>It appears then to me that this should become as a standard part
>
>>of the SDK, isn't it ?
>
>>Suppose that Apple decide to run the dsp code in another process
>
>>(as it is done in BeOS for efficiency) ; the solution that we are
>
>>talking about would not work then...
>
>>
>
>>Raphael
>
>_______________________________________________
>
>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.
>
_______________________________________________
>
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.
_______________________________________________
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.