Re: Cocoa and AudioUnits?
Re: Cocoa and AudioUnits?
- Subject: Re: Cocoa and AudioUnits?
- From: Robert Abernathy <email@hidden>
- Date: Mon, 27 Jan 2003 05:32:54 -0700
Sorry to comment on this again. I'll say this one thing and then be
quiet on the subject.
It isn't paranoia, or silly, or a conspiracy theory to think that Apple
feels greater pressure from certain developers than others. It also
makes sense that Apple listens and responds to the needs of these
companies. Every company I've worked at has whole departments
responsible for just this sort of interaction. They go under the
rubrics of Business Development or Strategic Relations. I also don't
think that there is anything wrong with Apple doing this. In fact, I
hope they do. What I wish would have happened is that one of the
companies with leverage had looked at Apple and said, "Hey, we want to
do our host in Cocoa!" (And no, I don't think that this is
unreasonable. I think it would have served them well.)
I brought the subject up, not because I couldn't see the reasons that
Apple took the path they did, but because when I looked through the
archives on the subject, I didn't see anything even remotely close to
"your voices have been heard." It seemed to me that the needs of the
Cocoa based developers were being minimized and dismissed. I'm glad
that I did bring up the subject, because I think that it has brought
out the point that there are developers who want/need to develop Cocoa
AU's even if they won't work in the Carbon hosts. I also hope that it
brought out the point that this isn't just a matter of convenience or
comfort. There are things that I would like to do in AU UI's that are
better served and done using Cocoa.
Thanks,
Rob
On Monday, January 27, 2003, at 02:12 AM, Benjamin Golinvaux wrote:
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.
_______________________________________________
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.