Category: Apple Pro Apps

Categories
Apple Pro Apps

How is Shake not Motion?

With the apparent demise of Shake – really nothing real now, as it seems to have been withdrawn from sale – Apple appears to be redirecting enquires to the Final Cut Studio 3 pages, suggesting that they consider Motion a substitute for Shake. I hope there’s something else coming (“Phenomenal” anyone?) because Motion is not a substitute.

Now, before I get into the reasons why they’re not interchangeable, let me say that it might make perfect business sense to drop Shake and not replace it. Shake, when Apple purchased it, had about 200 customers. That number has obviously grown dramatically but I’d be surprised if there were 10,000 true users: people who use Shake as the high-end compositing tool it was designed to be. It was also obvious that Shake, as it was, wasn’t going to be able to move forward in any serious way: no way to hook into GPU power or other such lush goodness.

Creating a replacement from scratch – all new, modern code – is an expensive operation. For a company like Apple, probably in the tens of millions of dollars to not only create the application but to test it internally (the Motion team, at time of launch, had as many QA people as software engineers), put the marketing plan into practice, run launch events, seminars, create training resources, etc. At Apple’s level, software is an expensive business.

The market for high end compositing software is small, and in the time Shake hasn’t been developed competitors have been significantly upgraded and taken market share from Shake. Maybe the decision was made to simply take what they could from Shake and roll it into Motion.

But Motion is not now, nor ever will be, a replacement for Shake. Motion is a great motion graphics tool with compositing capability. Shake is a compositing tool with some motion graphics capability. You see the problem.

Motion is an excellent motion graphics tool for video editors. It is designed to make it relatively easy for non-experts to create some fabulous looking motion graphics. Shake, OTOH, was for those individuals who were trying to track a head  shot against green screen onto a body while putting the whole body into a scene generated in 3D while adding other 3D characters.

This would be a nightmare to composite in Motion, because it’s not what Motion was designed for.

So, while it makes perfect sense to kill Shake – it was old and needed updating, and maybe updating doesn’t make economic or marketing sense – it doesn’t make sense to pretend that Motion is a suitable replacement.

I suspect that the original purchase of Shake was more for the marketing benefit of being associated with Tentpole movies rather than the income from software sales. Apple doesn’t need that so much anymore (and that’s a good thing).

I’d still like to see what the Nothing Real team would do recreating the application from the ground up with modern technologies, but I suspect Shake will never be anything real in the future.

Categories
Apple Pro Apps

Why I was wrong about ProRes

Since the launch of ProRes 422 in Final Cut Pro 6, I’ve been vocally disappointed that Apple didn’t choose to license Avid’s DNxHD family of codecs instead of developing their own competing (and almost identical) ProRes 422. Right down to the data rates used, the two codec families are very similar.

Except DNxHD is truly cross platform including *creating* files on Windows. Apple might not want to acknowledge it but the best high end compositing apps (Nuke et al.) are Windows and many of the highest end 3D apps are Windows only. That’s the world Apple’s customers live in and not having a way to create ProRes 422 on Windows is still a failing of that codec family. DNxHD codecs can carry alpha channels in all versions. Plus, if Apple had adopted DNxHD then media would be (sort of) compatible between Final Cut Pro and Media Composer. (A rewrap from MXF to QuickTime would be required, or the use of RayTools to read MXF natively into Final Cut Pro.)

But with the release of Final Cut Pro 7 and the new ProRes 4444 codec, I can see why Apple wanted to “do their own thing” as it were. They get to control the future of the codec family without involving third parties.

There’s no DNxHD 444 codec. There is now a ProRes 4444 codec and there is now alpha channel support for those who want it. (Admittedly I’d like to see alpha channel support in the 220 and 140 Mbit versions as well, but perhaps I shouldn’t be greedy.)

While it only duplicated DNxHD functionality (and really the new 45 Mbit Offline codec in ProRes duplicates the similar DNxHD 36 codec) it didn’t make sense to have competing offerings.

Giving us more than DNxHD does, makes up for the duplication.

But please, Apple, give us a way to create those files on Windows. I’m no Windows fan but this is the real world and Windows exists in media creation.

Categories
Apple Pro Apps Video Technology

What about Final Cut Pro 7?

I was prepared for a “small” release this time round, as I assumed that the Pro Apps Team would be working hard to convert to Cocoa and would have to release a smaller “interim” release, but Final Cut Pro 7 is definitely more than I was expecting.

Having iChat Theater built-in means no more workaround with remote collaboration using two Macs! It also suggests the Pro Apps folk “get” that remote collaboration is booming and they know they need to adapt to that world.

Likewise the new publishing palette is going to be great for a lot of editors who need to routinely provide progress updates and deliver them on the web. That it runs in the background while you continue working is even better. You could have saved a reference movie and sent that to Compressor and added an upload action to the preset, but this is just so much simpler, and gives direct access to the most popular sharing sites, and Mobile Me!  MobileMe might be the best choice for many editors – files can be private and certainly not as public as YouTube!

My all-out favorite features, while a small one, is that Markers in a Sequence now move with the Sequence as clips are inserted or deleted. Colored Markers are great and I’ll use them a lot to identify a type of marker. For example, one color could mean “more work needed here” another color would be a locator just you jump quickly to part of the Sequence, and so on.

The technologist in me is very impressed with the new ProRes codecs. Those that work at the high end will love the ProRes 4444 codecs (and those that want an alpha channel will use it anyway). The Proxy version at 36 Mbit/sec parallels Avid’s own DNxHD offline codec and Apple needed something similar for HD offline. The most interesting codec is, however, the 100 Mbit LT version.

Clearly aimed at acquisition I expect we’ll see camcorders and other devices, like maybe the Ki Pro, supporting this data rate, which is co-incidentally the same as AVC-I at its highest setting. AVC-I up against ProRes 422 LT would be very, very similar in quality, both 4:2:2 and 10 bit and using similar compression strategies. It would be a perfect data rate for the Ki Pro if AJA want to support it. (I can’t help but wonder if the last-minute-delay of the Ki Pro wasn’t to wait for this announcement, but I’m just guessing.)

The Pro Apps team have thrown a “sop” at those who want Blu-ray authoring with the ability to create a Blu-ray compatible H.264/AVC file in Compressor that can be burnt to Blu-ray or standard DVD media. Nothing that Toast 10 hasn’t been able to do for some time now but nice to have it included in the lower-cost Final Cut Studio.

Many have interpreted the inclusion of this feature as an indication that Apple are going to get “more serious” about Blu-ray, but I’m not sure. I think it indicates the opposite. If there was going to be a big Blu-ray push the these features would be added to DVD SP, which received almost no update in this version. I think we’ve got Apple’s “solution” for Blu-ray in Final Cut Studio. Who know, only the future (and probably a Product Manger at Apple) will tell. (The PM won’t ever tell, that’s for sure!)

As to the loss of LiveType. It was probably inevitable as it was increasingly obvious that Motion was taking on many of the roles previously done by LiveType. By adding in the LiveType glyph animation features to Motion (adopted directly from LiveType) most of the functionality is now in Motion. My only concern is whether Motion now recolors LiveFonts correctly (i.e. the way LiveType did). I’ll test as soon as I have a copy in hand.

Finally, the price. Who can complain about Final Cut Studio being the same prices now as Final Cut Pro was alone for the first couple of generations.

Certainly, on the surface, it’s a good release.

On the timing – I notice that all Pro Apps products – Studio, Server and Logic (Pro Music) all came out together for the first time. Does it mean anything? It’s Apple, who knows and I’d rather not drive myself crazy trying to second guess them!

Categories
Apple Pro Apps Metadata

What about the hidden metadata in Final Cut Pro?

We’ve been working with a few people previewing, and getting feedback on, a new addition to our First Cuts assisted editing tool – basically checking some areas of Final Cut Pro that I haven’t explored for years and I had the most interesting conversation with Jerry Hofman.

Before I get to that though, let me ask (beg) for feedback on any of our software products. We want to keep making them better and love feedback, feature requests and especially problems. We respond quickly – this particular feature request was received on Friday 26th, discussed briefly during a Hollywood Bowl concert on Saturday night and was a preliminary feature by Wednesday!

Anyhow, in discussing this particular tool with Jerry (you’ll find out what it is soon enough!) I asked how much metadata from RED is imported to Final Cut Pro via Log and Transfer. Jerry, who uses RED a whole lot more than me (i.e. he uses it!) said “not very much”, which pretty much matched my understanding working with a whole bunch of RED clips with Sync-N-Link and never seen any of the color temperature, date or other information that’s in the RED metadata.

In sharing this conversation with my smart partner, and our main code writer, Greg Clarke, he commented “Oh, I do think Mr Hofman is mistaken!” (or words to that effect). Turns out Greg has been scrolling past this metadata for most of the last year. The difference is that Greg works with FCP XML exports, while Jerry and I were looking through the Final Cut Pro interface.

OMG! What a treasure-trove of metadata there is. And why didn’t we know of this? Surely someone from all the conversations we’ve had with people developing Sync-N-Link must know about this? (You’ll all come out of the woodwork into the comments and let me know you’ve known about it for years!)

So this morning Greg’s built me a tool for exploring this hidden (I prefer “secret” because it makes it seem more mysterious) metadata, turning it into an excel spreadsheet. I already had XDCAM EX media and P2 media along with RED clips and I was able to download some AVCCAM media shot with Panasonic’s HMC-150 camera.

There’s an enormous amount of Source metadata there. A lot of fields that seems to be unused even in the camera. Clearly, the current version of Final Cut Pro doesn’t have the flexibility to display items like ‘whiteBalanceTint’ or ‘digitalGainBlue’ settings in the original file. I guess this type of metadata is going to be challenging for Apple and Avid to deal with, as they don’t (currently) have displays in their application for the enormous amount of metadata that are generated with tapeless cameras. I’m just very thankful that it’s being retained, and that it’s available via XML (and associated with a Final Cut Pro clip ID).

There’s definitely metadata already  being produced that we can use to improve First Cuts – at least for non-tape media sources. But it’s also interesting to explore fields that are available but not being used.

Show all columns and you'll be surprised at what's available, or going to become available.
Show all columns and you'll be surprised at what's available, or going to become available.

BTW, you can explore yourself using Log and Transfer. Open any type of media that Log and Transfer supports and then, right click on the column header (like you would in Final Cut Pro) and select “Show all Columns”. The columns displayed will change according to the type of media selected.

So far, Sony’s XDCAM EX has the least amount of metadata and the least interesting metadata – barely more than the basic video requirements and information on the device: model and serial number.  RED footage has a lot of metadata, although most is focused on the technical aspects of the shot as you would expect for a digital cinema camera.

But take a peak at the source metadata from P2 Media! All the goodness like the date of the shoot (which FCP otherwise does not export) and time (as does RED) but also fields for ‘Reporter Name’ (awesome for a First Cuts – News product) and Latitude and Longitude. While they’ve been blank in every instance because I don’t think Panasonic are shipping any cameras with GPS built in yet, it does suggest that future Panasonic cameras are likely to contain GPS and store that data in with the media file. Anyone who’s a regular reader will know that means Derived Metadata! There are also fields for ‘Location Source’, ‘Location Name’, ‘Program Name’, ‘Reporter’, ‘Purpose’and ‘Object’ (??).

AVCCAM carries all the fields of P2, more or less, with the addition of a “memo” and “memo creator” fields.

It’s been fun exploring this ‘secret’ metadata. Now to find a way to make some use of it, or make it practical. Would anyone be interested in a tool that would not only read and explore this metadata, but allow some of it to be mapped to existing Final Cut Pro fields?

Categories
Apple Pro Apps

What about Final Cut Studio and Snow Leopard?

In the comments on my article on “Why no ExpressCard 24 slot in the new MacBook Pro” Andreas asked about Final Cut Studio and Snow Leopard and I briefly responded there. Larry Jordan responded on his blog (Andreas asking him the same question) but not in any detail. Neither Larry nor I are programmers, but  I direct programmers every day – both OS X software and Web applications – so I do know a little. Plus I’ve tracked the technology development for FCP from version 1 onward – every change from OS 9 to OS X CFM, to OS X Mach-O to a hybrid application.

So, let’s see if I can manage a little clarity even if it’s only based on observation and deduction. As I said in the brief response, I have no clue what development Apple are doing and whether or not this is at all accurate. No doubt there will be engineers at Apple laughing at my naivety!

Carbon was the technology that Apple developed to let OS 9 applications run on OS X. It’s a set of programming interfaces (APIs) that individual applications call. There’s absolutely nothing wrong with Carbon, except that it can’t take advantage of any of the modern features of OS X – particularly those coming in Snow Leopard, nor can it run in 64 bit.

Cocoa is a different set of APIs, heavily drawn from NeXTSTEP – the NeXT operating system (Apple acquired NeXT in 1996). It is the preferred method for programming for OS X. In fact Apple have been pretty clear to its developers that, long term, Carbon will give way to Cocoa. They are encouraging all developers to get their code to “pure cocoa”.

When it looked like Apple were going to continue Carbon development with 64 bit APIs, as announced at the WWDC in 2006, there was really little incentive for Apple to spend the very many millions of dollars it will cost to rewrite FCP’s Carbon parts as Cocoa – to just get to where it is now. 64 bit Carbon was also Adobe’s preferred path for its older applications (Photoshop, Illustrator and After Effects). With 64 bit Carbon coming, Adobe could get 64 bit support without a major rewrite.

But when, at WWDC in 2007, Apple changed the rules and said, “No 64 bit Carbon”, any high-performance application had to think seriously about rewriting to Cocoa, at least long term.

We know, from public announcements, that Adobe had to delay 64 bit support for the named applications until CS 5 on OS X because of the time it takes to move applications to Cocoa and therefore 64 bit support.

All new features in FCP, since FCP 5 onward, have been written in Cocoa – HDV Log and Capture, Log and Transfer, Multicam, FXplug (that I know of) are all Cocoa. OS X lets programmers mix and match programming languages with ease. My guess is that Apple, like Adobe, would have continued with a hybrid approach with Final Cut Pro if the 64 bit Carbon APIs were going to be available. When they were not, the Pro Apps team, like Adobe, would have to have started porting their application to Cocoa. CS4 showed none of that progress, being released less than 2 years after the ’07 WWDC announcement.

Most of the FC Studio applications are new enough to have been written in Cocoa – the second revision of DVD Studio Pro (Spruce, not the Astarte-based DVD SP 1); Motion, LiveType, Soundtrack Pro and Compressor are all pure Cocoa applications and can (relatively) easily take advantage of 64 bit and/or Snow Leopard features like Grand Central Dispatch. I say “relatively” because there is still work to be done, that generally can’t start until Snow Leopard’s features are locked (i.e. WWDC 2009).

No responsible programmer is going to attempt to write for a new OS until the OS is locked and finished. So, theoretically, the engineers working on those applications could start NOW to work on Snow Leopard features, ready for a release in a year or two.

I can’t imagine that even the Cocoa-based Studio products will be taking advantage of any Snow Leopard features this time round – the timing is just all wrong. And they’re already Cocoa.

FCP, starting life at Macromedia as a cross-platform OS 9/Windows application, has most of the core written in Carbon. My (educated) guess is that it will take 2-3 years to rewrite all that code to Cocoa. I doubt they started that before WWDC 2007, as until then there was little incentive to invest many millions of dollars in a Cocoa rewrite. (Remember this is before the announcement of Snow Leopard, Grand Central Dispatch and OpenCL too.) Those features do provide an additional incentive to get FCP to “pure cocoa” (I estimate $10-15 million will be required to write, test, test, and I hope test what will effectively be v1 code again).

Apple will no doubt do that because the Final Cut Studio is highly profitable for the company from software sales only. (You don’t need to get too much from 1.25 million customers to make a viable business, even without taking into account any hardware sales, which don’t benefit the Pro Apps team at all.)

However, wanting to do it and having the time to do it are different things. They didn’t start (most probably) until after WWDC 2007 when they, and the Adobe teams, learnt that 64 Carbon wasn’t going to happen. Allow two to three  years to finish that job, before they can start to think about Snow-Leopard feature optimizations.

Pretty much every release of FCP requires the latest OS (the exceptions being FCP 3 which was for OS X and OS 9 both, and FCS 2 which is Leopard OSX 10.5 or Tiger OS X 10.4.11) and the latest QuickTime. So, I think that Studio 3 will, on the balance of probability, require Snow Leopard. Snow Leopard has no problem running 32 bit Cocoa applications at the same speed they always ran. As Snow Leopard has no PPC version, it could mean that FCS 3 may be not supported on PPC, we’ll have to wait for Apple to let us know. (FWIW, Adobe’s Production Premium CS4 is Intel only; Avid’s 3.x releases are Intel only, by way of reference.)

However, absolutely do not even think about running FCS 2 on anything newer than Leopard. In fact NEVER run FCP on any version of the OS or QT other than the ones that were directly supported. To do so is going to cause you problems, pain and regret. Old versions are never tested on the new OS and QT so there’s no reasonable expectation that they will run on a newer OS.

So, whether or not FCP 6 will run on Snow Leopard or not is irrelevant. Only an idiot would attempt it, and none of my readers are that stupid, right? Bank on an FCS upgrade to run the studio on Snow Leopard because it’s the only way to guarantee you’ll still be in business with an operating NLE after the upgrade.

Based on all that, the timing of Snow Leopard etc., it’s not really reasonable to expect that there will be Snow Leopard features in the next release, but we won’t know until Apple releases them. Until then, I guess we can all dream! 🙂

Categories
Apple Pro Apps Interesting Technology The Technology of Production Video Technology

Why Final Cut Pro specific cameras?

At the MacWorld Final Cut Pro User Group Supermeet on Wednesday night (Jan 7th) JVC announced two new ProHD camcorders. The 1/4″ progressive sensor 3-CCD compact (prosumer form factor) GY-HM100 and the shoulder mounted 1/3″ sensor GY-HM700.

There are a couple of things that make these two cameras interesting. They record in QuickTime native format ready for native editing in FCP. No import, no conversion – just copy and edit (or edit off the card). They also use SDHC compact memory cards instead of expensive proprietary formats. Both cameras have two card slots and with two 32 GB cards, can record up to 6 hours continuously for just a couple of hundred dollars.

You can read up on the rest of the specs but there are three points I’d want to make.

As far as I know this is the first camcorder made specifically for Final Cut Pro. While there have been some earlier attempts to make Avid-friendly camcorders, they didn’t hit it off in the marketplace. Clearly JVC see Final Cut Pro as a big enough market, with at least 1 million unique registered users (and probably twice that if unauthorized copies are counted) to justify doing a specific camcorder.

Secondly, increased use of SDHC. As well as these two new cameras the AVCHD/AVCCAM (Panasonic HMC-150) use compact flash as does the Red One camera. These are multi-vendor, non-proprietary formats that are readily available up to 32 GB. Take that P2 and SxS media! Of course, all these sources use compressed video of some format.

The third point is the most interesting one. JVC acknowledge that the camera does 720P at 19 or 35 Mbit/sec; 1080i at 25 Mbit/sec (aka HDV) and 1080P at 35 Mbit/sec using an “Enhanced MPEG2 Long GOP Encoder”. Traditionally ProHD has been working within the HDV specifications but there is no 35 Mbit/sec spec for HDV, particularly not one that’s already supported by Final Cut Pro. It appears that JVC are using Sony’s XDCAM EX format or something very like it, for these two new cameras.

This is not the first time JVC has worked with the Sony format. Back in September 2008 JVC announced support for XDCAM EX media and created a version for 720P licensed from Sony, which only supports 1080 in XDCAM EX.

Increasingly, Sony’s XDCAM EX format – at 35 Mbit/sec – is the grown up version of HDV.

Categories
Apple Pro Apps Interesting Technology

Assisted Editing – the beginning

I originally wrote this to a friend over the weekend and I thought that, with a bit of an edit, it might be interesting to some others.

Last week we released two new pieces of software through my long-time company, Intelligent Assistance, Inc: First Cuts and Finisher. Collectively we call the category “Assisted Editing” because they, well, assist the editor and going with Assistant Editor was getting confusing.

What I think makes this so exciting is that it’s the first real innovation in editing since Non-Linear Editing was popularized with the release of Avid’s Media Composer version 1, 19 years ago. 19 years is a long time in the computer business. Non-Linear Editing has certainly developed since that first release of Media Composer. Then 160 x 120 16 gray images were the “state of the art” while now we effortlessly manipulate High Definition (and beyond) images in our systems. But, despite this development, the way NLE systems work today is much the same as they did 20 years ago.

What Media Composer did, was to make the “cost” (time, effort, expense) of an edit much more affordable. With linear editing bays, making small changes to, or alternate versions, of a program was difficult (read expensive). Non-linear dropped the cost of a change, revision or alternate edit dramatically. Assisted Editing achieves similar dramatic cost reductions by allowing the computer (and specifically our software) to do some of the work of the editor.

Back at NAB in April we announced “The Assistant Editor” for long form documentary editing. After three months of beta testing we have now released that application as “First Cuts”. First Cuts (for Final Cut Pro right now but we’re exploring other platforms) take the log notes made by a documentary editor (or their assistant) and turns them into very, very fast first cuts. This allows editors and producers to explore the stories that are available in the material, and to juxtapose different versions while they seek inspiration and direction.

First Cuts take the log notes that long-form documentary editors have traditionally made (and their workflow) and makes them much more useful. The logged clips are exported from FCP as XML and opened in First Cuts, where the editor chooses opening title and lower third template (Motion templates preferred), the duration and story keywords that will be used for this edit. Within seconds it creates an edit with beginning, middle and end to the story arc, with opening title placeholder and fully finished Lower Third titles used appropriately to identify speakers on camera. The edit will also have b-roll used appropriately and the audio on the b-roll is lowered in volume and faded in and out. It’s an edit a producer or finance person can watch without being distracted by jump cuts or lack of visual interest from the absent b-roll. You can see the process in a quick five minute tour at the First Cuts home page.

First Cuts is primarily focused on long form documentary editors because they have the discipline to enter log notes (if they don’t they will have a very hard time of it) and because they need to explore a lot of material. The payback is significant. Fortunately there are a lot of documentary editors working with Final Cut Pro.

We discovered that one way of working with First Cuts would be to find a cut that was close to what was desired, and then the skilled editor would add the polish, trim and emotion that a first cut lacks. In doing that we discovered that blowing away the b-roll and titles was the cleanest workflow. Since that removes a lot of the time saving, we decided to make a product that restores that finishing effort. Hence, Finisher.

Finisher takes a project with an edited a-roll sequence (aka “radio edit”) and adds Lower Third titles and b-roll as above. This is the perfect bookend product to First Cuts.

But we worked out that we could do a lot more with Finisher for those who don’t want/need to enter a lot of log notes. Finisher will work with any of the log notes that are provided for First Cuts, but does not require them. In fact Finisher can randomly choose b-roll to place in a Sequence. Location of b-roll can be forced with Sequence Markers, so obvious jump cuts are covered first. While it can run with random selection it will use b-roll search terms in the comment field of those Sequence Markers and search for matching b-roll if available.

You can see some examples of Finisher’s work, including a guided tour that shows a couple of different ways it can work, at the Finisher home page. Particularly interesting is the final example – ‘Ode to the Beach’ – because that is a simple audio recording, some b-roll pulled out of my stock collection from Final Cut Server, and Finisher adds b-roll to the cut (with Sequence Markers) randomly. The result – for almost zero effort – is quite acceptable and may even be useful in some situations.

Not too shabby for a version 1 product.

Categories
Apple Apple Pro Apps Video Technology

ProRes 422 Explained

One of the currently popular memes is the “wisdom of the crowds” and if by crowd we mean a lot of people then there’s a lot of wisdom at CreativeCOW.net. Trouble is, it’s spread across a whole bunch of their forums so it takes a smart writer to take that wisdom and filter it down into something much more useful.

Well, the Cow’s Tim Wilson has done just that in two excellent articles:

Apple’s ProRes 4:2:2 Codec, Part 1 and
Apple’s ProRes 4:2;2 Codec, with a splash of Color, Part 2.

Highly recommended and well worth the read.

Categories
Apple Pro Apps Interesting Technology

XML Article at kenstone.net

Ken Stone has released an article I wrote on XML in the Final Cut Studio. The article is What is XML and what does it mean for Final Cut Studio users?

Also, Steve Douglas reviewed my company’s Pro Apps Tips, also at KenStone.net in the Pro Apps Tips Review.

Just thought you’d like to know. Oh, and in 2007, I’ll be posting more regularly as I evolve some of the thoughts around a book I’m working on, tentatively titled “Television 3.0”.

Categories
Apple Apple Pro Apps Business & Marketing Interesting Technology Random Thought

Don’t panic! Apple adopts Intel processors

The confusion and furor surrounding Apple CEO Steve Jobs’ announcement at the WordWide Developers Conference that future Mac, after Jun 2006, will use Intel processors inside is totally unfounded. Nothing changes now, very little changes in the next year and longer term the future for the Mac got a little brighter. Although the decision caught me by surprise, as I thought about it, and listened to what was said in the keynote, I could see why it made sense.

If we look short term, the decision makes little sense. Right now a G5 (Power PC, aka PPC) PowerMac has very similar performance to the best workstations on the PC/Intel platform running Windows and the G5 will cost less than a similarly performing PC workstation. At the low end the Mac mini is competitively priced to a cheap Dell or other name brand. (Macs are not price competitive with off-brand PCs, the so called “white box”.) So, why put the developer community, and developers within Apple, through the pain of a processor shift?

For the future (“we have to do it for the children”) and because it’s really not that painful for most developers.

Right now a G5 PowerMac is very performance competitive with the best offerings from Intel. What Apple have been privy to, that rest of us haven’t, is the future of both Intel processors and PPC processors. Based on that future Apple decided they had no choice but to make the change. In the future, the performance-per-watt of power of a PPC chip will be “15 units of processing” according to Mr Jobs. The same watt of energy would give 70 units of performance on an Intel processor. Without knowing exactly how those figures were derived, and what it means for real-world processing power it seems like a significant difference. It was enough to push Apple to make the change.

Not that there’s anything wrong with the PPC architecture: IBM continue to develop and use it at the high end and PPC chips (triple core “G5” chips) will power the Microsoft XBox360. The sales of chips to Microsoft will well and truly outweigh the loss of business from Apple. It is, however, a crazy world: next year will see a Microsoft product powered by PPC and Macintoshes powered by Intel!

Steve Jobs demonstrated how easy it will be for developers to port applications to OS X Intel. In fact, he confirmed long-term rumors that Apple have kept OS X running on Intel processors with every development on OS X – Mr Jobs demonstrated and ran his keynote from an Intel Macintosh. For most applications a simple recompile in the Xcode developer environment will suffice – a matter of a few hours work at most. Moreover, even if the developer does not recompile, Apple have a compatibility layer, called Rosetta, that will run pure PPC code on an Intel Mac. Both platforms are to be supported “well into the future”.

During the keynote Mathematica was demonstrated (huge application, 12 lines of code from 20 million needed changing, 2 hours work) as were office applications. Commitments to port Adobe’s creative suite and Microsoft’s Mac Business Unit software were presented. Apple have been working on Intel-compatible versions of all their internal applications according to Mr Jobs. [Added] Luxology’s president has since noted that their 3D modelling tool modo took just 20 minutes to port, because it was already Xcode-based, and built on modern Mach-0 code.

Remember, these applications are for an Intel-powered OS X Macintosh. No applications are being developed for Windows. In fact, after the keynote Senior Vice President Phil Schiller addressed the issue of Windows. Although it would be theoretically possible to run Windows on an Intel Macintosh it will not be possible to run OS X on anything but Apple Macintosh.

Apple’s Professional Video and Audio applications might not be as trivial to port although most of the modern suite should have no problem. LiveType, Soundtrack Pro, DVD Studio Pro and Motion are all new applications built in the Cocoa development environment and will port easily. Final Cut Pro may be less trivial to port. It has a heritage as a Carbon application, although the code has been tweaked for OS X over recent releases. More than most applications, Final Cut Pro relies on the Altivec vector processing of the PPC chip for its performance. But even there, the improvement in processor speeds on the Intel line at the time Intel Macs will be released are likely to be able to compensate for the loss of vector processing. At worst there will be a short-term dip in performance. However with Intel Macintoshes rolling out from June 2006 it’s likely we’ll see an optimized version of Final Cut Pro ready by the time it’s needed.

[Added] Another consideration is the move to using the GPU over the CPU. While the move to Intel chips makes no specific change to that migration – Graphics card drivers for OS X still need to be written for the workstation-class cards – Final Cut Pro could migrate to OS X technologies like Core Video to compensate for the lack of Altivec optimizations for certain functions, like compositing. Perhaps then, finally we could have real-time composite modes!

Will the announcement kill Apple’s hardware sales in the next year? Some certainly think so but consider this: if you need the fastest Macintosh you can get, buy now. There will always be a faster computer out in a year whatever you buy now. If your business does not need the fastest Mac now (and many don’t) then do what you’d always do: wait until it makes sense. The G5 you buy now will still be viable way longer than its speed will be useful in a professional post-production environment. It’s likely there will be speed-bumps in the current G5 line over the next year, as IBM gets better performance out of its chips. We are waiting for a new generation of chips from Intel before there would be any speed improvement. If Apple magically converted their current G5 line to the best chips Intel has to offer now, there would be little speed improvement: this change is for the future, not the present.

So, I don’t think it will affect hardware sales significantly. As a laptop user I’m not likely to upgrade to a new G4 laptop, but then there will be little speed boosts available there in the next year anyway. But as a laptop user, I’m keen to get a faster PowerBook and using an Intel chip will make that possible.

Although I have to say I initially discounted the reports late last week because, based on current chip developments, there seemed little advantage in a difficult architecture change. With the full picture revealed in the Keynote as to the long term advantages and the minimal discomfort for developers, it seems like a reasonable move that will change very little except give us faster macs in the future.

How could we have any problem with that?

[Added] Good FAQ from Giles Turnbull at O’Reilly’s Developer Weblog