Re: Setting the Number of Channels
Re: Setting the Number of Channels
- Subject: Re: Setting the Number of Channels
- From: Jeff Moore <email@hidden>
- Date: Thu, 19 Jun 2003 17:31:22 -0700
That came off a little heavier than I'd liked. Admittedly, C++ is my
"native" programming language, so I'm definitely biased. But in my
enthusiasm for my fun with mixing Cocoa with C++, I didn't mean to
slight the MTCoreAudio.framework. I have not personally used it and
others on this list speak very highly of it. All I wanted to point out
was that compilation speed is a silly reason for avoiding a solution to
a problem.
Eventually, I'll add one of my own ObjC++ Cocoa apps to our sample code
to show how well it works it practice. Put my money where my mouth is
so to speak. Plus, I'm sure the folks will be suitably horrified at how
much like C++ I can make my ObjC code look =)
On Thursday, June 19, 2003, at 11:22 AM, Jeff Moore wrote:
Not to further belabor the point, but what is going to slow down rapid
prototyping more, a slow compiler or not calling the API correctly
because you're using some mystery code that doesn't necessarily do the
right thing?
IMHO, you are better served with the slow compiler and the correct
usage of the APIs. The net effect is that you will worry less about
the APIs and more about what you are trying to do with them. And as
you say, there are other benefits as well to the tighter type checking
C++ gives you. One you might be overlooking is that ObjC method calls
are slower than non-virtual C++ method calls. Plus, C++ objects can be
allocated on the stack and used for resource management in a very
clean way.
Personally, I've been mixing Cocoa with C++ a lot for my own apps and
have been tremendously pleased with the combination despite the slow
compilation (which can be somewhat alleviated if you use the PFE
support in GCC3).
On Thursday, June 19, 2003, at 3:05 AM, Brian Willoughby wrote:
You're right, Bill, it is easy enough to use the C++
CAStreamBasicDescription
class within an ObjC project, but it sure slows down the compiler. I
remember
someone else complaining about how slow the ObjC++ compiler is, and
now that I
am using CAStreamBasicDescription in a Cocoa app, I know just what
they're
talking about. This really hurts rapid prototyping.
I haven't looked at MTCoreAudio.framework yet, but I am hoping that it
provides all of the functionality of CAStreamBasicDescription without
the
overhead.
One side-benefit is that the ObjC++ compiler forces you to write
"better"
ObjC! The ANSI C++ compiler is much more strict, so cleaning out the
warnings
is probably an improvement (although many of the compiler's
complaints are not
about "bad" code, per se).
Brian Willoughby
Sound Consulting
Begin forwarded message:
Subject: Re: Setting the Number of Channels
Cc: Michael Thornburgh <email@hidden>, CoreAudio API
<email@hidden>
To: Jeff Zacharias <email@hidden>
From: Bill Stewart <email@hidden>
At the risk of belabouring this point... :)
The classes in the SDK in PublicUtility will save you a lot of this
kind of trouble - in this case CAStreamBasicDescription or the other
one (we've unified these both so that's even better next SDK rev!)
takes care of these details for you and also provides things like
match
operators (operator==), etc...
Oh wait. its C++ ...
Don't Panic!
Its a very simple class (as are nearly if not all of the PublicUtility
classes) to use and doesn't dynamically allocate memory so there are
no
gc issues to resolve. It should be easy enough to use within an ObjC
environment...
Bill
_______________________________________________
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.
--
Jeff Moore
Core Audio
Apple
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.