Re: Cocoa and AudioUnits?
Re: Cocoa and AudioUnits?
- Subject: Re: Cocoa and AudioUnits?
- From: Benjamin Golinvaux <email@hidden>
- Date: Mon, 27 Jan 2003 10:12:15 +0100
rob and others:
1) try to develop two separate gui sdk (carbon and cocoa) for years and
then, try to use the view objects of one api inside the other :
probably not an easy job. The good news is : the events are compatible
since windows can be mixed. But there
are probably a lot of issues to solve regarding the views (ports etc...
i don't know carbon at all so i can't comment)
2) if apple had waited Q3 2003 to release the AU SDK with support for
both cocoa AND carbon views, would it have been any better for your
business ?
trust me it's painful for us too because we had a cocoa codebase for
proprietary plugins before the new AU sdk and no-one of us is a
"classic" Mac programmer (means we gotta learn carbon from scratch).
But thinking about political decisions when the technical challenge
seems very real looks like paranoia to me. Also, i think the fact that
apple people are organized in teams (hopefully they are.. picture the
mess it would be otherwise) probably makes it difficult for such tasks
where big interaction between teams is needed (and i repeat : already
being able to mix windows is a very good step... it's only recently
that the sample code to do this was released..... this probably means
cocoa+carbon interaction is NOT something trivial otherwise it would
have been done right from the start.... ). Same is true for
coreaudio/quicktime integration ,for example... it would be nice to be
able to use AUs for QT audio tracks natively inside a movie..... but it
requires integration and time...
Sorry to lengthen this already long thread, and no offense to those
missing the cocoa api : i understand even though i can't really be
angry about this
Benjamin Golinvaux
www.arboretum.com
On Saturday, Jan 25, 2003, at 23:22 Europe/Paris, Robert Abernathy
wrote:
Look, when Apple decided to define an API that allowed those Carbon
hosts to host Carbon AU's, that was a good business decision. When
Apple decided to exclude the use of other UI environments, that smells
of a political decision. How hard would it have been to add a
parameter to the AU that announces what type of view the AU wants?
Say, Carbon, Cocoa, X11, none- I'll do my own thank you, ... Then the
host can decide if it wants to include them in the list of available
AU's.
The arguments that no one (nobody important) would use other formats
for UI's, if their AU wouldn't work with the major hosts, are wrong.
For a counter example, let's look at Logic. When I look at the
contents of my copy, I see plugin synth modules that don't appear to
be AU's. I'm sure that Emagic has good business/design reasons for
doing this.
I don't understand why it isn't easy to see that a lot of people would
choose to develop using AU's that don't work with the major (Carbon)
hosts. So, I'll try a different angle. When I first looked at the
docs for AU's, my immediate reaction was "I don't need a host
environment anymore." AU's/CoreAudio/CoreMIDI are the host platform!
This isn't just an API for putting out VST's. You've got synths,
sequencers, output, mixers, ... Mix this up with a community of
developers/musicians. Excellent! Now, we still do have all of that
without Cocoa. Cocoa would simply provide acceleration.
I'm also confused as to why anyone is getting upset that people are
telling Apple (through the CoreAudio team) what we think and want.
I'm pretty sure that the reason the situation is the way it is now, is
because certain developers had the opportunity to express their views
on the subject. I (re)started this thread because I had a practical
business decision to make. I think it makes perfect sense for me to
say- and Apple to hear- what effect their decisions have on my and
others' business plans. In my case, if I have to eat the cost of
Carbon development, I might as well eat the costs of going completely
cross-platform. When I registered my last product with Apple, they
wanted to know if my product were Mac only. So, it seems they do care
about this.
I'm being told that this shouldn't be Apple's problem. They don't
have the resources to expend on Cocoa. It isn't their responsibility.
Well if it isn't theirs, then it must be mine. The only problem
there is that I can't even work on it. So, open the code- put it in
Darwin. Just the AU parts, that's enough. The world could use a good
open plugin standard.
Rob
_______________________________________________
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.