On Mon, Mar 1, 2010 at 4:03 AM, Greg Parker gpar...@apple.com wrote:
On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
I disagree. I have written very low latency device drivers in
Objective-C. Why do you think Objective-C has too much latency for audio?
When properly used, Objective-C
Le 1 mars 2010 à 05:55, Erik Buck a écrit :
On Feb 28, 2010, at 10:49 PM, David Rowland wrote:
On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
I disagree. I have written very low latency device drivers in Objective-C.
Why do you think Objective-C has too much latency for audio?
On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
I disagree. I have written very low latency device drivers in Objective-C.
Why do you think Objective-C has too much latency for audio? When properly
used, Objective-C programs are no more likely to be preempted than any other
kind of
On 26.02.2010, at 15:12, Sean McBride wrote:
the STL Debug mode is broken on 10.6, etc., etc. C++ support is good, but
it's not great.
I guess this is off-topic for this list, but could you maybe give a short link
or so regarding what the STL debug mode would be, and how it is broken? I'm
Hi,
everyone say: ObjC is slower then C++, but I/O Kit in the NextStep was
written in ObjC, I really don`t think Next`s engineers didn`t know that. Now
many crazy people write games in C# (managed language), but says that ObjC
is not appropriate because it dynamically. Your experience is greater
On Feb 28, 2010, at 11:39 PM, Eagle Offshore wrote:
There is no good reason not to have the base classes for AudioUnit be in
Objective-C rather than C++ other than the personal biases of certain
CoreAudio team members.
That's kind of insulting to those team members. The real reason is that
On Mar 1, 2010, at 12:22 PM, Jens Alfke wrote:
IMHO the worst problem with CoreAudio isn't what language it's in,
but that the APIs don't form a coherent framework, rather a
patchwork of complex procedural interfaces plus a pile of
undocumented, mostly-unsupported and poorly-structured
On Mon, Mar 1, 2010 at 9:22 AM, Jens Alfke j...@mooseyard.com wrote:
IMHO the worst problem with CoreAudio isn't what language it's in, but that
the APIs don't form a coherent framework, rather a patchwork of complex
procedural interfaces plus a pile of undocumented, mostly-unsupported and
There was a similar discussion on the coreaudio-api list a year ago,
it ended like this with an answer from one of the CoreAudio engineers:
From: William Stewart bi...@apple.com
I don't want a full-blown discussion here, but from everything we've
seen (including the guts of obj_message send)
On Mar 1, 2010, at 2:05 PM, Roni Music wrote:
There was a similar discussion on the coreaudio-api list a year ago,
And with this, I think we can close this discussion as no longer productive.
Greg Parker’s answer earlier in the thread should likely be considered
definitive.
scott
moderator
Carbon was originally Pascal based, at least as far as the APIs. It does not
essentially matter what it is written in, just what APIs it supports. If it has
been rewritten in C++ (are they mad?), that should make no difference to
whatever developer language is used, and would not be an argument
On Feb 28, 2010, at 1:20 AM, Ian Joyner wrote:
Carbon was originally Pascal based, at least as far as the APIs. It does not
essentially matter what it is written in, just what APIs it supports. If it
has been rewritten in C++ (are they mad?), that should make no difference to
whatever
On Sun, Feb 28, 2010 at 1:33 PM, Paul Bruneau
paul_brun...@special-lite.com wrote:
Or if you want to do a bunch of audio stuff in the iPhone, then you can enjoy
the experience of learning C++ even though all you want to do is obj-c.
Depressing.
Nothing in Core Audio requires you to use C++,
That is excellent and I really like the sound of it. Someone please inform the
authors of Apple's iPhone sample code so that I won't have to deal with C++
anymore! (I'm looking at YOU, SpeakHere!)
On Feb 28, 2010, at 10:24 PM, Erik Buck wrote:
I disagree. I have written very low latency
On Sun, Feb 28, 2010 at 7:24 PM, Erik Buck erik.b...@sbcglobal.net wrote:
I disagree. I have written very low latency device drivers in Objective-C.
Why do you think Objective-C has too much latency for audio? When properly
used, Objective-C programs are no more likely to be preempted than
On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
I disagree. I have written very low latency device drivers in Objective-C.
Why do you think Objective-C has too much latency for audio? When properly
used, Objective-C programs are no more likely to be preempted than any other
kind of
On Feb 28, 2010, at 7:35 PM, Paul Bruneau wrote:
That is excellent and I really like the sound of it. Someone please inform
the authors of Apple's iPhone sample code so that I won't have to deal with
C++ anymore! (I'm looking at YOU, SpeakHere!)
SpeakHere displays one of the things I like
On Feb 28, 2010, at 10:49 PM, David Rowland wrote:
On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
I disagree. I have written very low latency device drivers in Objective-C.
Why do you think Objective-C has too much latency for audio? When
properly used, Objective-C programs are no
All my audio render callbacks use the C-function-pointer-to-call-named-selector
trick in JambaLaya. (http://audiofreakshow.com)
In fact, the entire app is written in Objective-C. Between SnoizeMIDI,
MTCoreAudio, and my own private TBAudioUnits framework - I deal with C or C++
almost never.
On 2/25/10 4:54 PM, Nick Zitzmann said:
Second, C++ is a fine language, and is not going to be deprecated any
time soon, since a lot of stuff in the OS is written in C++ or ObjC++,
such as the Security and WebKit frameworks. The only problem with C++ is
the ABI keeps getting broken between
is Apple's Carbon basically code written in C++, while Cocoa is
written in Objective-C? should developers avoid using frameworks
written in C++ (like some sound frameworks)?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:
is Apple's Carbon basically code written in C++, while Cocoa is
written in Objective-C? should developers avoid using frameworks
written in C++ (like some sound frameworks)?
Why? Objective-C and C++ mix just fine as long as you follow a few
i've been reading about how apple dropped their plans for Carbon 64 a
while back, so if carbon is C++ then i'm surprised that apple is still
supporting it at all?
On Thu, Feb 25, 2010 at 6:42 PM, Dave Carrigan d...@rudedog.org wrote:
On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:
is Apple's
http://developer.apple.com/carbon/
http://en.wikipedia.org/wiki/Carbon_%28API%29
On Thu, Feb 25, 2010 at 15:40, Chunk 1978 chunk1...@gmail.com wrote:
is Apple's Carbon basically code written in C++, while Cocoa is
written in Objective-C? should developers avoid using frameworks
written in
On 26/02/2010, at 10:40 AM, Chunk 1978 wrote:
is Apple's Carbon basically code written in C++, while Cocoa is
written in Objective-C?
Some parts of Carbon is C++ internally, some is C, but the APIs are C.
should developers avoid using frameworks
written in C++ (like some sound frameworks
On Thu, Feb 25, 2010 at 6:42 PM, Dave Carrigan d...@rudedog.org wrote:
On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:
is Apple's Carbon basically code written in C++, while Cocoa is
written in Objective-C? should developers avoid using frameworks
written in C++ (like some sound frameworks)?
On Feb 25, 2010, at 4:45 PM, Chunk 1978 wrote:
i've been reading about how apple dropped their plans for Carbon 64 a
while back,
We just had a thread about this, but basically, Carbon is not dead; only parts
of it were taken out of the 64-bit frameworks.
so if carbon is C++ then i'm
On Thu, Feb 25, 2010 at 5:45 PM, Chunk 1978 chunk1...@gmail.com wrote:
i've been reading about how apple dropped their plans for Carbon 64 a
while back, so if carbon is C++ then i'm surprised that apple is still
supporting it at all?
You're confusing a library/framework with the language
On Thu, Feb 25, 2010 at 7:02 PM, Stephen J. Butler
stephen.but...@gmail.com wrote:
Apple has deprecated libraries/frameworks. They haven't stopped
supporting any languages though.
I'm pretty sure they no longer support Pascal. ;-)
sherm--
--
Cocoa programming in Perl:
On Feb 25, 2010, at 4:02 PM, Stephen J. Butler wrote:
Apple has deprecated libraries/frameworks. They haven't stopped
supporting any languages though.
Pretty sure we don't provide any Pascal or HyperCard tools anymore. I forget
whether we shipped gfortran at any point in Mac OS X.
In any
On Feb 25, 2010, at 4:08 PM, Greg Parker wrote:
Feel free to draw your own conclusions about Apple's future support for C++.
What Greg said. Note that a lot of major big-ticket Mac apps contain large
amounts of C++ code — Photoshop, MS Office, etc. Most cross-platform apps are
C++ at their
There's also the issue of the lifetime of the string. Will initSomeSystem
hang on to the char * after the call returns? If so, your code will blow up
since when the NSString goes it will take with it that C string--instead
you'd have use one of the calls that *copies* the C string into a buffer
Folks;
I'm an ObjC guy who has to deal with some Carbon code that looks like
this:
#define kVERSION abc
#define kPARTNUMBER 123
...
if ( (p_flag = initSomeSystem (
kVERSION,
On May 11, 2008, at 11:36 AM, Steve Cronin wrote:
Is this correct?
Is there a better way?
It depends. Does the code take a real C string (char array), or does
it take an Str63 or Str255 or something? If the latter, then you need
to use CoreFoundation to get a Pascal string from the
On 11 May '08, at 10:36 AM, Steve Cronin wrote:
const char * cPartNumber = [partNumber
cStringUsingEncoding:NSUTF8StringEncoding];
That looks correct, assuming the Carbon function does take a C string
in UTF-8 encoding, but you can make it a bit more compact:
const char *
Nick;
Thanks for the info, the deal is I don't have access to the source for
'initSomeSystem'.
So I can't answer your question, other than to point out what does
work..
I do know that ' #define kVersion abc ' creates a suitable string.
I'm trying to do the 'best' substitution I can with
On May 11, 2008, at 4:11 PM, Steve Cronin wrote:
If that is true, then is the following the best solution?
I guess it is then, unless initSomeSystem() modifies the character
array, in which case you may have a problem. You could also use -
UTF8String instead of -cStringUsingEncoding: if
37 matches
Mail list logo
