On Jan 25, 2007, at 2:41 PM, Richard Burnett wrote:
Thanks for the response!
Hi Richard - You're Welcome.
I think the thing that started me most was CocoaUI's not being supported in hosts, I just wasn't even aware that was an issue altogether.
As previously stated, Carbon is the way to go in my experience, though I would love to be disproved.
If I had known, I'd have started with Carbon instead.
When I have time to focus on AUs - I actually use Carbon, Cocoa, and Generic, depending on what I am trying to accomplish - which is usually just prototype and algorithms. In the back of my mind, I figure any commercial release would use Carbon.
The biggest problem with all this is that I am not a very heavily experienced OSX programmer. I've used WindowsAPI, MFC, OWL, DirectX and even some stuff in linux with GTK++ and LADSPA plugins. I instantly latched on to the CocoaUI stuff because it is VERY easy to write with and control the GUI.
I can only agree, since most of my experience is with Cocoa. It's also easier to use Carbon in Cocoa - as opposed to the other way around.
Urs Heckman (u-he) has posted another example which uses nibs:
The ( built ) example is pretty much the same as AUGUIfmwk.
Destroy FX at sourceforge...
Airy Andre ( who has done the AUGUIfmwk ) also has some AU examples.
That's what's coming to mind as what could have a nib and is publicly available.
Carbon...in simple terms...is not. It's much more like WindowsAPI it appears in how it handles things and what you have to do with it.
I wish that one of the sample examples that came with Xcode had a Carbon UI done in the interface builder and NOT creating the window from scratch. This is where I am having trouble because I have no example of how to do this.
You should have what you need to get a nib between the AUGUI and Urs' example.
I tried downloading all the AU example SDK libraries that others have created, however, these are done with much older versions of xcode (or pb) and either don't compile, or if I manage to fix up the code so they do, don't execute properly (wrong compiler options) AND THEN do not pass AUVAL. So I am left not having a good example of what it is that I am trying to do and getting quite overwhelmed while trying to learn at the same time.
You could prototype in your preferred fmwk or generic, then implement the view later... at least you will have time to test around.
I've written the makers of a few of the SDK's to see if they could release a version compiled with 2.4.1 and start from there. What I really just want is a project of a simple audio effect with a carbon interface done with the interface builder and all connected together. Most of the issue here, again, is me and where I am coming from.
I also see you have contacted MOTU - as wel as the other responses to this topic.
So, are you certainly off to use Carbon - or will you perhaps try Cocoa from another angle ( if possible)?
J