June 20, 2007

Thank you sir! May I please have another?!?

by Chris Randall

If you're the crafty sort, you can look at this page on the Apple site, and it might just give you hives. Big fat hives right on your face, with hairs growing out of them.

If you're not the crafty sort, you'll wonder "why?" The key cause for worry is in this paragraph:

In addition to the POSIX and math libraries supported in Tiger, Leopard enables developers to build complete 64-bit applications using the Cocoa, Quartz, OpenGL, and X11 GUI frameworks.

Guess what's not mentioned there? Carbon. That's the library that virtually all developers of audio software on the Apple platform use. You may not be intimately familiar with it, but suffice to say that Live, Cubase, Nuendo, ProTools, and even their own Logic are all written against the Carbon library. No 64-bit Carbon means no 64-bit audio apps, until all those developers port their various products to Apple's ridiculous Cocoa library and everyone learns Objective C.

Now, it's not as bad as all that. 32-bit Carbon will certainly be present in Leopard. (If it wasn't, roughly 95% of the apps written for OSX wouldn't work with Leopard.) But I wouldn't hold my breath for the next iteration of OS X having any 32-bit capabilities at all. It's not something you need to really worry about right this minute, as a user, but I'll state right here and now that if Carbon ceases to exist at all, it will effectively wipe out indie development for audio on the Macintosh.



Page 1 of 5

Jun.20.2007 @ 1:35 PM

they seem to take only part of 64-bit Carbon away. More details here

link [www.carbondev.co...]">link [www.carbondev.co...]



Jun.20.2007 @ 1:36 PM
Again?! Wow. How many times can Apple perform a stunt like this?

Jun.20.2007 @ 1:39 PM
Or any developer worth their weight can learn Cocoa, which is really not that hard, and incredibly more object oriented than Carbon.

Jun.20.2007 @ 1:39 PM
brandon daniel
And the real problems come in if/when the vst/au host apps go cocoa/64, then all the people writing plugins need to go Cocoa for compatibility.

Mass industry suckage.


Jun.20.2007 @ 1:52 PM
"Leopard introduces 64-bit support all the way up to the application level, which is the only difference (announced for Carbon and Cocoa last year, scaled back to Cocoa and non-UI Carbon this year). The details of that have been in the Leopard seeds for seed key holders for a year."

Jun.20.2007 @ 1:53 PM
Chris Randall
It's worth mentioning, Chris, that Eric Schlegel knows roughly as much about what Steve Jobs is going to tell him to do as I do.

From what I can tell, two things are true:

1) Certain higher-ups at Apple just said "we don't need Carbon anymore, do we?" without really thinking about the ramifications.

2) It won't affect the vast majority of audio developers until 10.6 (which I will affectionately term "Civet" until told otherwise) when they dump Carbon in its entirety and go to 64-bit through and through. And if you don't believe this is something Apple would do, I've literally got a _stack_ of Macintoshes, and right next to them, a _BOX_ of ADB and serial peripherals, that give lie to that.

In any event, this would only affect us if Logic were to go 64-bit. At that point we would almost certainly stop releasing AudioUnits, until Live and Cubase also went 64-bit on both Windows and OS X.



Jun.20.2007 @ 1:57 PM
Chris Randall
To Ataru: that's not entirely true; nobody said that you _COULDN'T_ use Carbon, because until the dev conference last week, Carbon was "First Citizen" of the 64-bit world. This is brand new.

Brandon: It will be roughly the same pruning as the PPC->Intel switch. All I can say on the matter is that I'm not going to be able to get Adam to write one plugin in C++ and another in Obj-C. We'll release in C++, and as long as we can do that cross-platform we will. When we can't, we won't. We're sick of Apple.

Oh, and Chris: The part of Carbon they take away is the part we need.



Jun.20.2007 @ 2:03 PM
I agree that Apple doesn't have the track record that Microsoft does with backwards compatibility. (Read Raymond Chen to see how much that compatibility costs MS to achieve.) But I have a few quibbles here.

1) You can code against CoreAudio with C/C++. Many Cocoa APIs were initially difficult to use without Objective-C, owing to poor documentation, design assumptions, etc. But this is not the case with CoreAudio.

2) Speaking from experience, I can say that it does suck when you're trying to port software from 32 to 64-bit, and some of the libraries you're using aren't available in 64-bit versions. But in this case, Carbon is an old, long-frozen API, lacking many modern features that CoreAudio offers, and the upgrade path is not terribly difficult. If you're taking the time to port your app to 64-bit, you might as well look into moving to CoreAudio. Don't want to? Just stay 32-bit.

3) It would suck if Apple stops shipping a 32-bit Carbon solution on 64-bit OSX while there are still popular 32-bit Carbon apps out there. But I don't think they're likely to do this, since it will cost them nothing to keep providing the libraries. They already stopped maintaing Carbon for the most part. So I think you're jumping the gun in getting angry about that possibility.


Jun.20.2007 @ 2:08 PM
I should say that I am not currently doing OS X audio development professionally. For large apps I'm likely wrong about the upgrade path to CoreAudio being "not terribly difficult".

Jun.20.2007 @ 2:32 PM
Chris Randall
It's worth noting, Dewb, that almost nothing you mentioned has any bearing on what we do. The whole "oh, it's easy, just do it crowd," of which you are obviously a member, never takes in to account the fact that one would have to branch one's code to develop for both Windows and OS X. Do you imagine it would be fun and profitable for us to write a plugin in C++ for Windows, then re-write it in Obj-C for OS X?

And if you don't believe your #3 would happen, you're quite simply out of your mind. The Power PC was the Most Powerful CPU On The Planet up until the day before the Dell dev systems used for Intel development started going out the door.



Page 1 of 5



Sorry, commenting is closed for this blog entry.