Re: AudioUnits and Cocoa UI
Re: AudioUnits and Cocoa UI
- Subject: Re: AudioUnits and Cocoa UI
- From: Urs Heckmann <email@hidden>
- Date: Tue, 18 Mar 2003 09:07:36 +0100
Am Dienstag, 18.03.03, um 02:41 Uhr (Europe/Berlin) schrieb Andy:
On Monday, Mar 17, 2003, at 17:03 Europe/London, Bill Stewart wrote:
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
...
This is good news indeed :) But can we be assured that at least the
Apple owned Logic will support this feature ?
Not much point in supporting it if Logic is not a capable host.
Although some of us are indeed writing host apps with cocoa based
front ends, Logic is likely to be the most important factor in terms
of market for individual AUs. I am very pleased that at last some
serious discussion about cocoa views can happen.
I think at least one example should be given in the CoreAudio SDK...
... maybe someone contribute it?
Reg. Logic and support by apps, I see that we already have that pending
issue in respect of Compositing Windows. I hope we can get some example
code or an update of AUCarbonViewBase for that, too. (I think it's
about removing EmbedControl and using HIView APIs instead). That way,
support for nested Controls would be nice as well...
I'm pretty sure that the SDK's example code sets the standard. So I
suspect it has to be in there...
...
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...
As is known by some, I have already proved that this method can and
does work for AUs. In fact the method I implemented is almost exactly
as you describe, (apart from your forthcoming protocol of course) and
so I am confident your proposal will work OK.
But I am concerned that some complex AUs will need more than one
window/view. We only need to look at some of the samplers that are
appearing in the VSTi domain to see that a single view really is not
enough. Perhaps before steaming ahead with the cocoa protocol we
should at least discuss this feature. Cocoa is an ideal API for a
multiple view AU. I know we need to be careful here as it could easily
get out of hand so perhaps time for discussion about some rules for
multi view AUs ??
He he, I discussed multiple view support with Emagic (it's already
prepared in the specs, see that AUBase::GetNumGUIComponents), but they
hadn't had any concrete idea about how, if and when. It may take some
time until the actual use of such will be obvious. (Like newbie view,
expert view)
But your view can easily open new windows dynamically. I
(experimentally) use a transparent Overlay Window to display "special
effects" (little explosions when you hit nasty buttons), and it just
works fine (unless your view sits inside a floater, but that's just
cosmetic stuff). I think it wouldn't even be a big problem to open a
window and ask the process to give you a description for a subview
component which you then host by yourself. On the other hand, just
installing controls and binding them to parameter schemes seems just as
easy.
One thing that I don't like on the idea of multiple windows is the
waste of screen estate. My beta testers voted for Tabbed Panes and
dynamic changes instead of multiple windows. So this is where I go.
Wouldn't Cocoa windows provide those drawers?
Cheers,
;) Urs
_______________________________________________
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.