Re: AU with Multiple Carbon Views
Re: AU with Multiple Carbon Views
- Subject: Re: AU with Multiple Carbon Views
- From: William Stewart <email@hidden>
- Date: Wed, 25 Nov 2009 16:01:56 -0800
the .r file - that has the following definitions (this is taken from
the sample effect)
//
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// SampleEffectUnit
#define RES_ID kAudioUnitResID_SampleEffectUnit
#define COMP_TYPE kAudioUnitType_Effect
#define COMP_SUBTYPE 'Pass' // this effect just passes audio through
#define COMP_MANUF 'Acme' // note that Apple has reserved all all-
lower-case 4-char codes for its own use.
// Be sure to include at least one
upper-case character in each of your codes.
#define VERSION kSampleEffectUnitVersion
#define NAME "Acme Inc: SampleEffectUnit"
#define DESCRIPTION "Acme Inc's favorite audio effect"
#define ENTRY_POINT "SampleEffectUnitEntry"
The ENTRY_POINT here is the name of the C function that is generated
from COMPONENT_ENTRY
The version we usually include in a header file (as its used in two
places, here and in the GetVersion() method call from ComponentBase)
This builds a resource file that is then part of your bundle. This is
then used by the coreservicesd to register your audio unit as the
type, sub, manu, with the entry point from that bundle that it will
dispatch calls through.
Bill
On Nov 25, 2009, at 3:52 PM, Darrell Gibson wrote:
Bill,
Thanks for your reply. I think in my own mind I had conclude that
the sub-view should be done within the parent view, as you
suggested. I just really want reassuerance that this was correct.
(I have since found the AUPulseDetector example which using its
GenericAUView class seems to do a similar thing.)
Just for my own understanding, if I did use a single entry point how
do I determine the version? Sorry if the answer is obvious, but I
just can't "see it" at the moment.
Thanks again,
Darrell.
________________________________________
From: William Stewart [email@hidden]
Sent: 25 November 2009 20:48
To: Darrell Gibson
Cc: email@hidden
Subject: Re: AU with Multiple Carbon Views
As you really have a view that has options to create sub views, then
you should do this within your parent view I think (which is what you
describe) and just manage this as an internal resource, rather than
exposing this is multiple views...
However, if you want to do this as multiple views, all that
COMPONENT_ENTRY does is creates a "C" function pointer that is
exported and becomes the entry for a given component type.
You can use the same entry point for different components (and then
when your actual C++ class is instantiated, you can find out which way
you were opened). We do this for instance with the AUTimePitch, which
has both a 'aufc' and 'auol' version and uses the same entry point for
both types.
Bill
On Nov 25, 2009, at 2:31 AM, Darrell Gibson wrote:
Hi All,
I want to create an AU that has multiple UI views (two in the first
instance). The first one is for the plug-in itself and I have
implemented. This window has a button on it that should then open a
second window for another UI with additional parameters on it.
I have tried creating the second view class, but it seems I can only
apply one view entry point to the carbon view component.
I could create one view class that would create two windows, but as
the COMPONENT_ENTRY is used I have not control over use of the class.
Is there an alternative to the COMPONENT_ENTRY for registering a
view? What is the correct method for having multiple view? Are
there any example?
Thanks for any help or pointers,
Darrell.
BU - the UK's Number One New University
The Guardian University Guide 2009 & 2010
This email is intended only for the person to whom it is addressed
and may contain confidential information. If you have received this
email in error, please notify the sender and delete this email,
which must not be copied, distributed or disclosed to any other
person.
Any views or opinions presented are solely those of the author and
do not necessarily represent those of Bournemouth University or its
subsidiary companies. Nor can any contract be formed on behalf of
the University or its subsidiary companies via email.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
_______________________________________________
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