Re: Confused about AU <-> AUView communication
Re: Confused about AU <-> AUView communication
- Subject: Re: Confused about AU <-> AUView communication
- From: Chris Rogers <email@hidden>
- Date: Mon, 25 Nov 2002 14:42:58 -0800
Malcolm,
The model is that an AudioUnit does not present ANY user interface by
itself, but rather presents parameters and properties for configuring it.
User-defined properties may be implemented by the AudioUnit which
allow the passing back and
forth of arbitrary data.
For example, in your case, your MusicEffect requires a file.
You could implement a property specifying a file (FSRef, CFURL, FSSpec,
for example). Separate from the AudioUnit is an AudioUnitCarbonView
component (notice that both the AudioUnit and the AudioUnitCarbonView
are components -- this is important). You can make a custom
AudioUnitCarbonView
which is able to talk to your AudioUnit via a property for specifying
a file which comes from a dialog box which the AudioUnitCarbonView brings
up. The hosting application can then create an instance of your AudioUnit and
AudioUnitCarbonView in such a way that the view communicates to the AudioUnit
by using the AudioUnitCarbonViewCreate() call.
I want to make one thing very clear. The AudioUnit *itself* should NOT
be creating any user interface either directly or by opening a
AudioUnitCarbonView instance. This is for the hosting code to do...
I hope this is able to answer your questions...
Chris Rogers
Core Audio
Apple Computer
Hi All,
I've been busy tying myself in knots trying to get a AUCarbonViewBase
class talk to a MusicEffects class. Im unclear as to the exact
relationship between the two, especially when there is more than one
instance of the plugin in a Logic song.
Under VST things are very simple: A VST plugin creates the editor and
there is a simple 1-1 relationship, which makes communicating easy. If
a parameter changes in one then it makes sure that the other is
updated. As I understand this is not the same under AU.
In my AU plugin there are no parameters as there is a button which
opens a load-file dialog. The file alias is stored with the song. This
was difficult to implement with parameters. It was much easier to talk
directly between the AU and editor as for the VST plugin.
When a AU is created then it calls AUCarbonViewBase::CreateCarbonView
which calls CreateUI for my editors view. Here I can get direct access
to the plugin as it was the last AU to call AUBase::GetProperty. I can
change settings in the editor and they will update the AU directly
(bypassing any parameter calls).
Now I create a 2nd instance of the AU and it opens itself in the 1st
AUs window (with default values as it should).
Q: Is this the same AUCarbonViewBase object as the first plugin?
Q: Can I get it to open a new window and retain a 1-1 relationship with
the AU?
Now when I reopen the first AU it uses the same view but does not
update itself to the correct settings but retains the 2nd AUs
(default) settings.
Could someone please explain how the two are working together and what
would be my simplest option. Id much rather the simplicity of VST.
Thanks very much,
Malcolm Haylock
_______________________________________________
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.