Re: Cocoa views for AU
Re: Cocoa views for AU
- Subject: Re: Cocoa views for AU
- From: Michael <email@hidden>
- Date: Thu, 21 Aug 2003 09:53:16 -0700
Patrick, Airy, et al,
The protocol Bill posted on the list in March has changed slightly. It
has been simplified to the following:
#import <Cocoa/Cocoa.h>
#include <AudioUnit/AudioUnit.h>
@protocol AUCocoaUIBase
// Returns the version of the interface you are implementing
// In Mac OS X v10.3, this is 0
- (unsigned) interfaceVersion;
// Returns the NSView responsible for displaying the interface for the
provided AudioUnit
- (NSView *) uiViewForAudioUnit:(AudioUnit)inAudioUnit
withSize:(NSSize)inPreferredSize;
@end
The AudioUnitCocoaView structure is unchanged. Our latest SDK we will
be releasing shortly has complete documentation on how to write
CocoaUI's and we have added a cocoa ui to the SampleEffect unit that
ships with the SDK. Furthermore, we have a cocoa host sample app for
people that are interested in that sort of thing. For those of you that
are interested in writing CocoaUIs for your audio unit, I'd be happy to
help you with any questions you have until the SDK is released.
-Michael
On Thursday, August 21, 2003, at 06:59 AM, Airy Andri wrote:
>
You can find the protocol as defined by Bill Stewart in this list in
>
March.
>
As far as I know, no change has been made public since then.
>
Please note I have no AU ready for this yet.
>
But if there some developers interest for it (and host writers too, of
>
course - but the two are quite linked), I may go for a Cocoa version
>
of AUGUIFramework, with a bunch of NSView classes and IB palettes to
>
use for AU Cocoa GUI development.
>
I am quite sure a lot of developers here would like to use Cocoa for
>
their UI development.
>
>
Airy
>
>
Here is a copy of the Bill proposal :
>
-----
>
From: Bill Stewart <email@hidden>
>
Subject: AudioUnits and Cocoa UI
>
Date: lundi 17 mars 2003 18:03:48 Europe/Paris
>
To: email@hidden
>
>
OK...
>
>
Here we go.
>
>
This is a proposal that I want to pass by this list before we set this
>
in stone that would enable an AudioUnit to communicate to a host that
>
it has a UI that has been written for it in Cocoa.
>
>
We looked at trying to provide a bridge that would present the same API
>
for both Carbon and Cocoa hosts, but this seems untenable at this time
>
(primarily because in a Carbon app, any Cocoa code has to run in its
>
own window and that window *cannot* be drawn in or interacted with as
>
if it were a Carbon window)... As many host apps like to have toolbars
>
on their plugin windows, to do so with a Cocoa view would require Cocoa
>
code anyway.... The good news though, is that it is not that difficult
>
for a Carbon app to have a cocoa window within it, there is an example
>
of this in the Carbon SDK (CocoaInCarbon), so if Carbon hosts *want* to
>
do this (and we aren't requiring this either - just to be clear), they
>
can...
>
>
So once in place this will leave us with the following relations:
>
Carbon View - Carbon App
>
Carbon View - Cocoa App - needs to be in a separate "Carbon" window,
>
but can have other Cocoa code around it
>
Cocoa View - Carbon App - can be embedded in a "Cocoa" window - only
>
has Cocoa code (ie. no Carbon drawing, controls)
>
Cocoa View - Cocoa App
>
>
I should also make it clear that the most easily and broadly supported
>
UI is still Carbon, so if any AU developer is concerned at this point
>
about broad usability, a Carbon View is certainly more broadly
>
supported. However, we also understand the attractiveness of Cocoa for
>
UI development and see a great potential for the sharing of UI objects
>
and widgets that can make this both an interesting and worthwhile
>
endeavour (how do you spell that!).
>
>
OK - the details:
>
Each audio unit that supports a cocoa UI view must support the
>
following property: kAudioUnitProperty_CocoaUI
>
>
The value of this property is the following struct:
>
>
typedef struct AudioUnitCocoaViewInfo {
>
CFURLRef mCocoaAUViewBundleLocation;
>
CFStringRef mCocoaAUViewClass[1];
>
};
>
>
mCocoaAUViewBundleLocation - contains the location of the bundle which
>
the host app can then use to locate the bundle
>
mCocoaAUViewClass - contains the names of the classes that implements
>
the required protocol for an AUView
>
>
The AU can return an array of these view info structures (similar to
>
the CarbonUI view component id's), and the host can easily determine
>
how many of these are present through the size of the property itself.
>
>
We will also define a protocol that we expect Cocoa AU Views to
>
implement:
>
>
#import <Cocoa/Cocoa.h>
>
>
@protocol AUCocoaUIBase
>
>
// Returns version of the interface youre implementing
>
// You should return 0 for now.
>
- (unsigned) interfaceVersion;
>
>
// Returns NSView responsible for displaying the interface
>
- (NSView *) uiViewWithSize : (NSSize) inPreferredSize;
>
>
// Returns an array of AudioUnitParameters bound to the
>
// view or control at the specified location in the uiView
>
- (NSArray *) paramListForControlAtLocationInView:
>
(NSPoint) pt;
>
@end
>
>
The paramListForControlAtLocationInView defines a method that a host
>
can use (similar to the Carbon Views) to control the over-dubbing of
>
parameter values. The Carbon approach provides a callback to notify
>
hosts of user interactions. However, this approach is not convenient
>
for cocoa developers because it would potentially require the plugin
>
view to override NSResponders mouseDown: method for every control in
>
the view in order to invoke a similar callback. This can be especially
>
cumbersome if InterfaceBuilder is used to make the nib file. Instead,
>
it is suggested that the host trap mouseDown events in the plugin view
>
by overriding sendEvent: in either a subclass of NSApplication or
>
NSWindow. When the host is recording automation, it would trap
>
NSLeftMouseDown events. If the event occurs in the coordinate space of
>
the plugin view, the host can call paramListForControlAtLocationInView:
>
with the location of the event (in view-relative coordinate space) to
>
determine the parameter (or parameters) that it needs to record until
>
the next NSLeftMouseUp.
>
>
The AU Views would be responsible for implementing the
>
paramListForControlAtLocationInView: method specified in the
>
CocoaAUView protocol. This method should determine which subview or
>
control is at the specified point and then return an NSArray of
>
AudioUnitParameters for the matching control.
>
>
Packaging
>
It is recommended that each UI bundle reside in the component package
>
of the audio unit that owns it. The bundle should reside in a Plug-ins
>
directory at the top level of the component. The bundle should have a
>
.bundle extension.
>
>
Localization
>
Bundles should be designed with localization in mind. All strings and
>
other resources to be localized should be stored in the appropriate
>
location: Contents/Resources/English.lproj (for example).
>
>
>
Host Application Responsibilities
>
Cocoa Host apps would get the Audio Unit component and then query the
>
kAudioUnitProperty_CocoaUI property to see if the audio unit has a
>
cocoa ui.
>
>
The following method in NSBundle can be used to get a class for the
>
string:
>
>
- (Class) classNamed: (NSString *) className
>
>
The class can then be instantiated using [Class alloc] init;.
>
>
Once the class is instantiated, the host can get the ui view by calling
>
uiView which returns an NSView. It is the responsibility of the host to
>
check the size of the returned NSView and install it in a scroll pane
>
if it is too big to fit in the desired location.
>
>
Comments are welcome.
>
>
Whilst we will eventually publish this protocol and propertyID in our
>
headers, this does not need any specific support from us, so if there
>
is a general agreement we can go ahead with this. At that time, I'll
>
give out the property ID number and away we go...
>
>
Bill
>
>
>
>
On jeudi 21 ao{t 2003, at 15:25, Patrick Gostovic wrote:
>
>
> I am writing a host in cocoa, but I was not aware of any standard
>
> mechanism for obtaining a handle on a cocoa view from an AU. If
>
> there is a way, please enlighten me and I will support it.
>
>
>
> pg
>
>
>
> On Thursday, August 21, 2003, at 07:19 AM, Airy Andri wrote:
>
>
>
>> Is there any host writer working at supporting Cocoa views for AU ?
>
>>
>
>> Airy
>
>> _______________________________________________
>
>> 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.