Re: Obj-C APIs for CoreAudio (was Latest Documentation)
Re: Obj-C APIs for CoreAudio (was Latest Documentation)
- Subject: Re: Obj-C APIs for CoreAudio (was Latest Documentation)
- From: Bill Stewart <email@hidden>
- Date: Thu, 14 Feb 2002 11:02:41 -0800
Some points about the Java side:
(1) It is NOT a trivial task to call C API's from Java and requires
additional libraries aside from the Java code that you write to call it
(2) In the last 12 months Java has become the most widely used language in
the world. To suggest that it is not interesting is naove. One of the most
impressive music apps that was being demonstrated at NAMM running on X was
Storm - written in Java...
This is not to belittle the possibility of doing something more for Obj-C.
But here's the difference. Obj-C is a parser around C, so your Obj-C code
can call C APIs directly - there's no patching or glue involved.
I understand the interest that higher level APIs provide - there are already
some pretty powerful and easy to use APIs in the AudioToolbox already - the
Sequencing and AUGraph APIs are both good examples of this. I believe our
fundamental responsibility is to provide good, reliable and solid
implementations of those types of services.
As I said before, I don't think it is particularly interesting or valuable
to provide wrapper classes for Obj-C like we've done in Java. The more
interesting possibilities are defining classes that are targetted to
specific needs - to use a class to encapsulate some functionality that you
can both re-use and/or manage in a more controlled manner for dev and debug
purposes. Aside from being a consumer of object heirarchies you should
really cut your teeth on designing and implementing classes for your own
projects.
Without Java APIs that task is onerous for many purely Java based
developers. It is far less onerous (at the cost of a little bit of reading
and the Java models can serve as a guide if you feel) for Obj-C developers
because they can call the APIs directly (yes, I know they are lower level,
but there is not that much hidden in the Java classes anyway and you have to
deal with the same issues ultimately).
I really don't buy the Carbon complaints. The only part of Carbon that we
use in any real way is the Component manager - and that is a packaging
mechanism solely for the audio units. The example in Java/SDK/FindUnits can
show probably all you need to know about that (as can the other examples of
constructing graphs - like SMFPlayer for instance).
Just because it is a C API does not mean that it is a Carbon API... You
don't have to learn Carbon to use CoreAudio. If you have to do a little bit
of work to understand the basics of what you are dealing with, then you
should look at what benefits you get from that - a better, more tailored
implementation and a broader understanding of the subject matter..
I could go on, but I won't.
Despite my ranting:) I am not ruling out us doing something with Obj-C - it
is obvious that there is a strong interest in it from some of you. At this
stage I'm not making any promises or commitments to doing something with it,
or if we did, what that would be. So you should be clear about that.
MusicKit is in open source at sourceforge and I understand that it has been
brought up on Core Audio...
Finally....
If there are areas in CoreAudio that are difficult to deal with from
Obj-C/Cocoa, then we shall fix it - or at least debate it:)
Bill
on 13/2/02 10:46 PM, Larry Van Peursem wrote:
>
YES! YES! YES! Both! Third Party? Apple? I don't care! I'll Pay for
>
ABCMusicFramework! Newbie Cocoa loving dude here just wanting to do
>
some simple stuff without having to decipher the Ninja voodoo!
>
Quicktime Musical Instruments for Cocoa with good docs would rock my
>
world. Apologies for my naivety. Need abstraction beyond Core Audio.
>
Something like MusicKit but complete and documented for the somewhat
>
uninitiated. Is that asking too much? ;-)
>
>
Thanks,
>
Larry
>
>
>
>
> Does anyone know how many folks on this list would like ObjC api's?
>
>
>
> Count my vote for an ObjC API (both CA and QT) and useful
>
> documentation.
>
>
>
> Apple gives us QT for Java and a Java API for CA, but how many people
>
> here are writing Java apps?
>
>
>
> Kevin
>
>
>
>
>
> On Wednesday, February 13, 2002, at 07:18 PM, Bill Stewart wrote:
>
>
>
>> on 13/2/02 2:45 PM, Jonathan Feinberg wrote:
>
>>
>
>>>> CoreAudio is (at its name indicated) in the range of the "Core"
>
>>>> services : that is neither Carbon, neither Cocoa, but intended to be
>
>>>> used by both of them. C is then a "natural" choice for the
>
>>>> programming language of such services (i.e CoreGraphics,
>
>>>> CoreFoundation, CoreServices...).
>
>>>
>
>>> Agreed! For this reason, it would be convenient to have access to
>
>>> documentation which reflects the usage of CoreAudio from the
>
>>> perspective of a C programmer.
>
>>>
>
>> Which is what the pdf does (admittedly in an incomplete format). But
>
>> then
>
>> there are the header files and this email list (which are there as a
>
>> resource for you to use).
>
>>
>
>> We've made no comments or promises about an Obj-C API for it - its a
>
>> good
>
>> 3rd party opportunity:) So, then you need to think... What do I want to
>
>> do
>
>> and what objects do I need - this is a very different question than
>
>> just
>
>> wrapping up C APIs (which at least from Obj-C's standpoint is a
>
>> convenience
>
>> more than anything else)
>
>>
>
>>> Does such documentation exist? As far as I can tell it does not.
>
>>> The kind of documentation I'm looking for does exist for Java
>
>>> programmers, and can be found at
>
>>>
>
>>> /Developer/Documentation/CoreAudio/Java
>
>>
>
>> The pdf isn't on the build releases at the moment, but is available at
>
>> the
>
>> web site.
>
>>
>
>>> There is one document that gives an overview of CoreAudio, with some
>
>>> C headers and minimal sample code, as it was defined in May of 2001.
>
>>> I have referred to this document in earlier posts to this list. I
>
>>> wonder whether that document has since been updated to reflect
>
>>> whatever changes might have been made since that time, or whether any
>
>>> new documents have been released, which address the usage of the
>
>>> CoreAudio framework and its constituent APIs.
>
>>
>
>> Nope...
>
>>
>
>> (and to add my comment to another post on this topic... The AudioUnit
>
>> SDK is
>
>> available through the ADC program and it is FREE to enroll as an online
>
>> member)
>
>>
>
>>> Thanks.
>
>>
>
>>
>
>> mailto:email@hidden
>
>> tel: +1 408 974 4056
>
>> __________________________________________________________________________
>
>> "We'll talk about it later...."
>
>> "When?"
>
>> "In a future life when we're both cats"
>
>> __________________________________________________________________________
>
>> _______________________________________________
>
>> 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.
>
>
>
>
>
> End of coreaudio-api Digest
>
_______________________________________________
>
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
__________________________________________________________________________
"We'll talk about it later...."
"When?"
"In a future life when we're both cats"
__________________________________________________________________________
_______________________________________________
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.