Atom Feed
RSS Feed
Buy Mike Recommended
edit systems & gear
from Silverado Systems
Buy Books, Software, & More
at HD for Indies Amazon Store
Buy New Movies from
HD for Indies Amazon Store
Or, you can also support
HD4NDs by contributing
to the tip jar...
Help Support HD for Indies
RSS Feed
Buy Mike Recommended
edit systems & gear
from Silverado Systems
Buy Books, Software, & More
at HD for Indies Amazon Store
Buy New Movies from
HD for Indies Amazon Store
Or, you can also support
HD4NDs by contributing
to the tip jar...
Help Support HD for Indies
Advertisements
Great HD Links
- HD For Indies Home Page
- HD For Indies FAQ
- HD 24
- Cinematography
- Bare Feats
- 24p Entertainment
- Digital Praxis
- OneRiver Codec Resource
- CamcorderInfo.com
- LumiereHD
- HighDef.org Info
- Understanding RAID
- Video Systems (Reviews)
- DV Film (DV=>Film)
- SonyHDVInfo.com
- Plus 8 Digital (vendor)
- Digital Cinema Society
- Texas High Def (local F900 guy)
- Creative Cow (news & forums)
- Philadelphia FCP User Group
- Los Angeles FCP User Group
- Cinema Tech
- FresHDV
- DV Info's forums
- HVX User
- Pro App Tips
- Bluesky Media - Instruction
- RedUser.net
- fxguide
- little frog in high def
- VideoMaker Learning Section
- Stu Maschwitz's ProLost
Archives
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
High Definition Video for Independent Filmmakers
A How To Guide for Digital Filmmakers
Welcome all! This is my blog to share my latest research,
thoughts, etc. on utilizing HD for independent filmmaking.
YES, I am available for consulting
Contact me at mike@hdforindies.com
All content copyright 2004-2007 Mike Curtis.
Tuesday, June 07, 2005
Final Cut Pro 5 Under the Hood - What's Different from v4.5
I got an interesting email today from a reader that went spelunking around in the guts of the Final Cut Pro 5 package contents (inside the actual application file). Here's what he had to say, think about the Cocoa (native OS X, easier to port to OS X on Intel) rather than Carbon (much more work to port) statements:
Hi Mike,
I have followed your Blog for a while and thoroughly enjoy the stories you choose to cover and write, not least because they generally go much further than the 'mainstream' production articles, reviews and 'news bites'.
Anyway, enough praising :-) I received my Final Cut Studio upgrade recently and I was very keen to have a good dig around the inside to see just what they had really been up to. I can't dispute that the new features are all welcome additions, but I was left with an overwhelming feeling that the Pro apps team where only keeping up with appearances with this release; i.e. they wanted to put a new version out with the other new apps which have received much more attention, but at the same time, FCP still stands out like a sore thumb due to its clear interface differences and the fact that a flagship Apple app is not cocoa based and using the ProKit UI framework.
With the old version of FCP 4.5, going into the app 'Contents' and looking around revealed that the app its self was still identified as a Classic app.
The only frameworks included were for profiling, registration, the audio mix engine and motion interchange.
There were no nib files and no interface images to be found as you would expect with a cocoa app such as Compressor.
Now with FCP 5.0, there a number of very interesting changes which suggest a little more what I had thought; this is a stop gap release and the Pro Apps guys are working feverishly to move FCP to a modern, Mac OS X code base built around cocoa. We have been given a number of new features but I think these have simply been brought down from a future WIP version to keep the app going until they are ready to announce a major, major new version.
Firstly the app inside the contents is no longer a Classic app, but is a Unix executable. There are now 13 frameworks included in the app, all of which appear to have been built in XCode or at least using more modern Mac OS X code - the header files reveal some feverish work since NAB last year!
Most of the new features come with modern Interface builder GUI's, such as the HDV capture and the various 'Send To' command pop ups. The Cinema Tools bundle is another example. Up until now, new feature additions have not been built on these modern standards, but rather it seems been built in the 'old' carbon way.
The new frameworks appear to herald something much more interesting for the future. My guess is that the whole app is being moved in this direction and it may mean they are able to build in many new enhancements under the hood, which would be very good. It seems the various tools of FCP are being slowly re-written as modern framework plugins. This might mean it would be possible for 3rd party devs to write their own framework additions to extend the app.
Disclaimer :-)
- Of course this is all mostly speculation!
- I am not a developer and am therefore making plenty of guesses.
- Its perhaps common sense to think that they are moving FCP to the same modern code as the other Pro Apps.
I was interested to know what your opinions were on this with regard to the future of the app, maybe you have a better understanding of what it could mean to move to this new code (scripting and extensibility and SDK's for example).
All the best
Mark
This implies to me that this publicly shipping version of Final Cut Pro 5 will require some pretty beefy retooling in order to run on OS X86 (what I'm calling, until there's a better official name, the OS X on Intel operating system). Between Altivec and non-Cocoa portions, even to get the current feature set running stably, at full native speed on Intel hardware, with comparable performance and stability compared to a dual G5, will be a goodly chunk of work. Adding new features and getting them to work fast & stably on both platforms will be yet another goodly chunk of work. If Final Cut Pro 6 is announced and/or ships in a timely fashion after NAB 2006 with MacIntel (Intel on Mac) support, I'll be duly impressed and satisfied.
Hi Mike,
I have followed your Blog for a while and thoroughly enjoy the stories you choose to cover and write, not least because they generally go much further than the 'mainstream' production articles, reviews and 'news bites'.
Anyway, enough praising :-) I received my Final Cut Studio upgrade recently and I was very keen to have a good dig around the inside to see just what they had really been up to. I can't dispute that the new features are all welcome additions, but I was left with an overwhelming feeling that the Pro apps team where only keeping up with appearances with this release; i.e. they wanted to put a new version out with the other new apps which have received much more attention, but at the same time, FCP still stands out like a sore thumb due to its clear interface differences and the fact that a flagship Apple app is not cocoa based and using the ProKit UI framework.
With the old version of FCP 4.5, going into the app 'Contents' and looking around revealed that the app its self was still identified as a Classic app.
The only frameworks included were for profiling, registration, the audio mix engine and motion interchange.
There were no nib files and no interface images to be found as you would expect with a cocoa app such as Compressor.
Now with FCP 5.0, there a number of very interesting changes which suggest a little more what I had thought; this is a stop gap release and the Pro Apps guys are working feverishly to move FCP to a modern, Mac OS X code base built around cocoa. We have been given a number of new features but I think these have simply been brought down from a future WIP version to keep the app going until they are ready to announce a major, major new version.
Firstly the app inside the contents is no longer a Classic app, but is a Unix executable. There are now 13 frameworks included in the app, all of which appear to have been built in XCode or at least using more modern Mac OS X code - the header files reveal some feverish work since NAB last year!
Most of the new features come with modern Interface builder GUI's, such as the HDV capture and the various 'Send To' command pop ups. The Cinema Tools bundle is another example. Up until now, new feature additions have not been built on these modern standards, but rather it seems been built in the 'old' carbon way.
The new frameworks appear to herald something much more interesting for the future. My guess is that the whole app is being moved in this direction and it may mean they are able to build in many new enhancements under the hood, which would be very good. It seems the various tools of FCP are being slowly re-written as modern framework plugins. This might mean it would be possible for 3rd party devs to write their own framework additions to extend the app.
Disclaimer :-)
- Of course this is all mostly speculation!
- I am not a developer and am therefore making plenty of guesses.
- Its perhaps common sense to think that they are moving FCP to the same modern code as the other Pro Apps.
I was interested to know what your opinions were on this with regard to the future of the app, maybe you have a better understanding of what it could mean to move to this new code (scripting and extensibility and SDK's for example).
All the best
Mark
This implies to me that this publicly shipping version of Final Cut Pro 5 will require some pretty beefy retooling in order to run on OS X86 (what I'm calling, until there's a better official name, the OS X on Intel operating system). Between Altivec and non-Cocoa portions, even to get the current feature set running stably, at full native speed on Intel hardware, with comparable performance and stability compared to a dual G5, will be a goodly chunk of work. Adding new features and getting them to work fast & stably on both platforms will be yet another goodly chunk of work. If Final Cut Pro 6 is announced and/or ships in a timely fashion after NAB 2006 with MacIntel (Intel on Mac) support, I'll be duly impressed and satisfied.
Comments:
I doubt they'll ever make FCP a Cocoa-app it'd be too slow, and it already is fully Carbonized or it wouldn't work on OS X at all.
All that's happening is that they are using more modern tools (XCode, Interface builder) to create the new bits, still using Carbon code. This will only need a recompilation to run on x86 (I have code here that has during it's lifecycle, been developed under Windows, Linux (x86), and OS X (G3) and should still work fine on all platforms -- it really isn't hard, especially when the OS will be identical).
The Altivec stuff is what will need to be rewritten, but to quote Apple's docs, they have already done the hard part of the task (which is formulating the code in a vector manner). In fact, I would not be at all surprised if it hasn't been done already internally. QT7 is already running on the x86 architecture (as demoed by Steve Jobs in the keynote and also seen in QT7 for windows) so Apple obviously know how to write this code on x86. The same goes for people like Blackmagic, who have windows versions of the code.
I would be utterly amazed (not least because it'd be commercial suicide for Apple) if they do not have x86-native versions of their pro-apps when they launch x86 Macs -- after all, people are going to want to run them on their new mac and Apple have stated that Altivec-based code will not run under Rosetta.
All that's happening is that they are using more modern tools (XCode, Interface builder) to create the new bits, still using Carbon code. This will only need a recompilation to run on x86 (I have code here that has during it's lifecycle, been developed under Windows, Linux (x86), and OS X (G3) and should still work fine on all platforms -- it really isn't hard, especially when the OS will be identical).
The Altivec stuff is what will need to be rewritten, but to quote Apple's docs, they have already done the hard part of the task (which is formulating the code in a vector manner). In fact, I would not be at all surprised if it hasn't been done already internally. QT7 is already running on the x86 architecture (as demoed by Steve Jobs in the keynote and also seen in QT7 for windows) so Apple obviously know how to write this code on x86. The same goes for people like Blackmagic, who have windows versions of the code.
I would be utterly amazed (not least because it'd be commercial suicide for Apple) if they do not have x86-native versions of their pro-apps when they launch x86 Macs -- after all, people are going to want to run them on their new mac and Apple have stated that Altivec-based code will not run under Rosetta.
# posted by 
: Wed Jun 08, 05:48:00 AM CST
: Wed Jun 08, 05:48:00 AM CST
You can have a Carbon app with an executable in ./Contents. Just to point out also that FCP is Apples most heavily copy-protected product. Cocoa is difficult to copy-protect. It will be very interesting to see how this is coped with on x86.
# posted by : Fri Jun 10, 05:45:00 PM CST
: Fri Jun 10, 05:45:00 PM CST
Anonymous (directly above) - I bet that they add some new copy protection features in Xcode 2.2, due in a year or so (total guess)
Post a Comment
Links to this post:
