• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AudioUnits and Cocoa UI
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AudioUnits and Cocoa UI


  • Subject: Re: AudioUnits and Cocoa UI
  • From: Bill Stewart <email@hidden>
  • Date: Tue, 18 Mar 2003 09:40:33 -0800

On Tuesday, March 18, 2003, at 12:07 AM, Urs Heckmann wrote:

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?

We have an example - but if there's a more complete one we'll gladly look at it.

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)

The idea of the multiple views are NOT currently aimed at providing a solution to this problem - this is more for the case where you might have *alternative* UI views - though I must admit we really haven't fleshed this out as it hasn't been a high priority (and noone has shown much interest in it)

Its an area we can explore more (but at a later date I think)

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.

I would definately support that conclusion as well... At some point, if your plugin needs multiple windows you have to ask whether its really appropriate usage, good UI for a plugin...

Bill


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.


-- mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __
_______________________________________________
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.
  • Follow-Ups:
    • Re: AudioUnits and Cocoa UI
      • From: Chris Reed <email@hidden>
    • Re: AudioUnits and Cocoa UI
      • From: Robert Abernathy <email@hidden>
References: 
 >Re: AudioUnits and Cocoa UI (From: Urs Heckmann <email@hidden>)

  • Prev by Date: Re: Error -10108
  • Next by Date: Sound Mgr crash in LinearInterpolate16
  • Previous by thread: Re: AudioUnits and Cocoa UI
  • Next by thread: Re: AudioUnits and Cocoa UI
  • Index(es):
    • Date
    • Thread