Re: Cocoa and AudioUnits?
Re: Cocoa and AudioUnits?
- Subject: Re: Cocoa and AudioUnits?
- From: Andy <email@hidden>
- Date: Sat, 25 Jan 2003 12:25:01 +0000
I promise this will be my last gripe on this subject but I do feel
strongly about this...
On Thursday, January 23, 2003, at 02:00 PM, Bill Stewart wrote:
I really don't get it - what problem! This is part of my frustration
with some of the comments on this thread
Please don't be offended but I don't get you, what exactly are you
trying to do with core-audio ? Are you creating a new and exciting
audio platform or are you simply playing with the big boys ? is this
some kind of corporate politic ? Fair game, a couple of very popular
applications are the only market for most plugin developers... but
that's not a good reason to downgrade the UI API.
Surely if all we wanted was a truly portable API that works with
existing applications we would never have had any use for audio-units!
Actually what we have currently to develop UIs for our AUs is not much
better than VST. A single non-compositing window with limited event
handling that relies on the host to correctly set it up. (Of course
that is /not/ the case with an NSWindow or NSView)
The amount of time I spent getting carbon controls to composite
properly was ridiculous, and that was even using the C++ classes that
Apple provide. I could have got a VST interface working in half of the
time, and a cocoa interface would have taken half of that (subclassing
NSControl is so easy and it works!). At the time it started to make me
angry, a feeling I haven't had toward my Mac for years !! :-) We
already have a huge and very good API for the rapid development of UI
on Mac OS X, it's called Cocoa!
I have previously proved to myself that an audio-unit can load and
present a working Cocoa window by loading the nib from a separate file
and launching cocoa using the techniques described (by Apple) in the
cocoa in carbon examples. (Of coarse the original carbon view cannot be
avoided).
So, if it's possible for an AU to load an open it's own Cocoa windows
why is it /not/ possible from within a carbon host application ?
Of coarse, the question is rhetorical.... It /is/ possible for a carbon
app to present a cocoa window to a plugin client. That is the approach
that /should/ have been taken. Ok so Logic would have had trouble
drawing it's (annoying) little button bar into the top of the window,
so what ? It is preferable imho for applications to fit properly with
the OS that they sit on, in this case (music) they /never/ have. One
only has to browse around the "historically" popular audio/midi
sequencers for a while to see just how much they hark back to even
their Atari roots, they ooze the awkwardness of their history.
And again of coarse it is possible for a cocoa host to provide a carbon
window, but why the heck would it want to ?
On Thursday, Jan 23, 2003, at 21:42 Europe/London, Robert Abernathy
wrote:
The "problem" is that we can't write our AU's using Cocoa. I would
write my AU using Cocoa even if the two major hosting apps couldn't
use them. Just like I would tend to write my AUs not using VST even
though that is relatively more restricting. View it as inducement (no
matter how small) to get those major hosting apps to do the right
thing. I personally think that if some of those major apps had
decided to do major overhauls, they might actually be to market by >
now.
Besides, this is only one view of how to use AU's. Another view would
be that I want to build a complete synthesis environment that
leverages the fine work you guys have done on CoreAudio and CoreMIDI.
One of the results of that nice work is the structure and
extensibility that AU's provide. This would be true even if there
weren't an army of 3rd party developers that make this an even more
obvious choice. Some of the things I would like to do in the modules
I want to build would benefit greatly from using Cocoa from the UI.
Plus I think my time to market would be less, if I could use Cocoa to
build these elements of the application.
Major platform changes are one of the few times that there are
openings in the software world for companies that don't already have a
"major" application out. So, I care deeply that Apple provides me
with the tools that give me the greatest advantage in trying to use
those openings. I really couldn't care less about making sure that
what I do, fits with two other companies products at the moment. If I
did, I'd just use VST.
I agree with this sentiment totally.
....
... now back to coding my AUs whose "carbon" user interfaces are now
working very well apart from very slow drawing ;-)
...
_______________________________________________
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.