Re: AudioUnitGetParameterProc
Re: AudioUnitGetParameterProc
- Subject: Re: AudioUnitGetParameterProc
- From: William Stewart <email@hidden>
- Date: Mon, 12 Apr 2004 16:02:06 -0700
OK
So you have to do A....
The question is why :)
MIDI Messages are parsed to the synth by the host application (or in
your case the sequence player)... They are done as a separate API call
than AudioUnit parameter calls... for a number of reasons.
There are listeners (which is what you are really meaning when you talk
about the GetParameterProc) that can tell you when a parameter's value
is changed.. (See <AudioToolbox/AudioUnitUtilities.h>) - but you can't
do this for MIDI messages (like Note On's for exaample)
So, if your UI needs to update as you are playing back a MIDI file,
then you will need to use an iterator - its not a big deal
Bill
On 12/04/2004, at 12:21 PM, Benjamin Schneider wrote:
>
Sorry for the confusion. I'm guessing my limited knowledge of the API
>
vocabulary is what's getting in the way here. I appreciate your
>
patience.
>
>
I'm creating an application that creates a MIDI client and an AU
>
Graph. The AU Graph contains the synthNode using the DLSMusicDevice
>
and the default output node. In addition, I have created a
>
MusicSequence and successfully played MIDI files through the
>
DLSMusicDevice via the sequence's SetAUGraph and LoadSMF calls. All
>
connections, etc. are working as expected. So now for the area in
>
which I'm having trouble...
>
>
Regardless of whether a parameter change is sent via a MIDI message
>
from an external source or comes from a MIDI file, I need to be able
>
to visually reflect these changes via my user interface. As I
>
understand it (which could be incorrect), I have two ways to
>
accomplish this...
>
>
A: When dealing with MIDI messages being sent to the client from an
>
external source, I can simply parse the data from my MIDIIncomingData
>
callback routine and use those MIDI messages to update my on-screen
>
controls; When dealing with MIDI files, create a MusicEventIterator,
>
continually poll my player for its current position, seek the
>
MusicEventIterator and use MusicEventIteratorGetEventInfo to get the
>
MIDI data for that moment in time and parse it to update my on-screen
>
controls.
>
>
B: Register my AudioUnitGetParameterProc so that whenever a parameter
>
change is made to my DLSMusicDevice, I can then update my on-screen
>
controls with the values for the changed parameter.
>
>
My preference is to use option B but I can't figure out how to
>
register my AudioUnitGetParameterProc.
>
>
Am I on the right track? If so, how to register my
>
AudioUnitGetParameterProc? If not, please enlighten me. ;-)
>
>
Thanks,
>
>
Ben
>
>
On Apr 12, 2004, at 1:22 PM, William Stewart wrote:
>
>
> So there are some confusing comments here...
>
>
>
> AU's are meant to be used as an API... whilst of course it is
>
> possible,
>
> its not really intended that an AU should instantiate another AU (in
>
> fact mostly this is backwards...)
>
>
>
> Perhaps it would be better to provide a short, concise description of
>
> what you are trying to do? If you want to just play MIDI files, then
>
> have a closer look at the PlaySequence sample code... that should give
>
> you some pointers about API you need to know about, the relationship
>
> between an AU and an AUGraph (and in that particular case) how they
>
> can
>
> be related to timing services provided by the Sequence and
>
> SequencePlayer objects
>
>
>
> Bill
>
>
>
> On 11/04/2004, at 7:03 PM, Benjamin J. Schneider wrote:
>
>
>
>> Thanks for the pointer to the CAAudioUnit code. I do, however, have
>
>> more questions.
>
>>
>
>> The AU I am working with instantiates the DLSMusicDevice component.
>
>> I
>
>> have it receiving MIDI and playing MIDI files. What I'd like to do
>
>> is
>
>> show parameter changes (pan, pitch bend, etc.) in sort of a "flying
>
>> faders" automation mode. Based on the constants given in the
>
>> documentation, I assumed I could use the AudioUnitGetParameterProc to
>
>> do this but I'm still not understanding how as the CAAudioUnit.cpp
>
>> file has very little commenting and I can't find robust documentation
>
>> anywhere. So...
>
>>
>
>> Am I to use AudioUnitGetProperty call, passing my function pointer in
>
>> the outData param? Maybe I'm being ignorant here, but that's what it
>
>> looks like is happening in this sample, but I can't re-implement it
>
>> as
>
>> the pointer is being modified, thus causing my app to crash. I was
>
>> unable to find other places where the function pointer was passed.
>
>>
>
>> If AudioUnitGetProperty isn't correct, should I be using something
>
>> like AudioUnitAddPropertyListener or AudioUnitAddRenderNotify, etc?
>
>> Those make more sense to me, but I'm admittedly lost.
>
>>
>
>> Sorry for the ignorance and thanks for the help,
>
>>
>
>> Ben
>
>>
>
>> On Apr 9, 2004, at 8:09 PM, William Stewart wrote:
>
>>
>
>>> In the current SDK (http://developer.apple.com/audio) there's code
>
>>> in
>
>>> the Public Utility source CAAudioUnit that does this
>
>>>
>
>>> Bill
>
>>>
>
>>> On 09/04/2004, at 2:14 PM, Benjamin Schneider wrote:
>
>>>
>
>>>> Hi all,
>
>>>>
>
>>>> Please excuse the rudimentary question, but please answer ;-)
>
>>>>
>
>>>> In many cases, a pointer to a callback procedure is a parameter of
>
>>>> an
>
>>>> initialization function, etc. In the case of
>
>>>> AudioUnitGetParameterProc and other similar callback definitions, I
>
>>>> can't find reference to how to tell the AU to use this procedure.
>
>>>> Can
>
>>>> anyone point me to a document or sample that shows how to set this
>
>>>> up?
>
>>>>
>
>>>> Thanks,
>
>>>>
>
>>>> Ben
>
>>>> _______________________________________________
>
>>>> 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.
>
>>>>
>
>>>>
>
>>> -- mailto:email@hidden
>
>>> tel: +1 408 974 4056
>
>>>
>
>>> ____________________________________________________________________
>
>>> __
>
>>> __
>
>>> __
>
>>> Culture Ship Names:
>
>>> Ravished By The Sheer Implausibility Of That Last Statement
>
>>> I said, I've Got A Big Stick [OU]
>
>>> Inappropiate Response [OU]
>
>>> Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
>
>>> ____________________________________________________________________
>
>>> __
>
>>> __
>
>>> __
>
>>> _______________________________________________
>
>>> 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.
>
>>>
>
>>
>
>>
>
> --
>
> mailto:email@hidden
>
> tel: +1 408 974 4056
>
>
>
> ______________________________________________________________________
>
> __
>
> __
>
> Culture Ship Names:
>
> Ravished By The Sheer Implausibility Of That Last Statement
>
> I said, I've Got A Big Stick [OU]
>
> Inappropiate Response [OU]
>
> Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
>
> ______________________________________________________________________
>
> __
>
> __
>
> _______________________________________________
>
> 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.
>
>
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.