7toX for Final Cut Pro

Media needs to be online during export from FCP 7 (or 6); during the conversion process (as 7toX checks details from the media) and during import to FCP X.

7toX for Final Cut Pro is expected to work with FCP 6 XML, but it is untested.

Unfortunately Final Cut Express does not export XML so we are unable to update Final Cut Express Projects.

Video Output

Video Output requires new drivers for your hardware. As of today only AJA have a beta of their FCP X output drivers available. Blackmagic Design and Matrox are expected to have betas of their drivers shortly. It’s important to note that these drivers are the first ever to be written to the new CoreMediaIO services on OS X. Previous drivers have all been QuickTime based, so this is all new work, not a simple update to drivers as previous versions were. That’s also why the video output is Lion only: only Lion has the foundations in place for the Core services functions needed, and work couldn’t start on the drivers until Lion was out, and a beta version of FCP X was available for hardware companies to work with.

As expected there is support for broadcast video out via third party hardware, although that feature is currently “in beta”: it works but not as well as Apple and the hardware folk would like. It’s available for those who need to use it. One less reason to not use Final Cut Pro X.

Multicam in Final Cut Pro 7 was definitely a tool for those who knew what they were doing. In Final Cut Pro X multicam is super simple: mix frame sizes, codecs and frame rates in different angles. I love that we can open the multiclip group into a Timeline and simply drag angles up or down to change their order; or to add filters to one or more angles; or add (or remove) angles from the multicam group without needing to remake the group. Another nice feature is to add in an audio only “angle” and tell Final Cut Pro X to use the audio from that angle, without switching audio.

Multicam, like so much of Final Cut Pro X, is a rethink that considered what would make multicam more accessible to more people by eliminating the “hard parts”: let the software adapt rather than forcing a certain level of knowledge on users. (Sorry for those who had this somewhat hard earned knowledge, but that is the way things move.) For example, the default way of making a multicam group is to base it on the audio waveforms. (Timecode, start points and other options are available.)

Other terrific new features not pre-announced are support for layered Photoshop files and reconnect media, which work pretty much as you’d expect. Also unexpected is an Advanced Chroma Keyer with more controls available. The basic key is still pretty darn good, but having advanced tools for cleaning up is valuable for those tricker keys.

Oh, and one other thing: Intelligent Assistance (that’s us) have released 7toX for Final Cut Pro. Bring your Final Cut Pro 7 projects forward to Final Cut Pro X. For the story, check out my post on 7toX for Final Cut Pro.

We have broadcast video out for those who need it, still in beta because it’s now based on the new CoreMediaIO instead of QuickTime and this is the first time AJA, Blackmagic Design or Matrox have ever worked with these Core Services, so it’s reasonable to cut them some slack. AJA have drivers ready today, with the others following up shortly. It must be hard for those guys having to constantly keep up with new versions of drivers for Avid’s Media Composer 6 and presumably some new version of Premiere Pro since Al Mooney strongly implied we would hear more about the next version of the Creative Suite “around NAB”, extrapolating from the previous two releases.

We have a great implementation of multicam. We have layered Photoshop support and reconnect media, and we have a way of moving Projects forward. That seems to have addressed most of the “deal breakers” people have had. Bottom line now is that we’re at the point where it’s now possible to evaluate Final Cut Pro X on its own merits: not how similar or not it is to other applications, but as a viable alternative editing interface.

I don’t expect that everyone will suddenly jump in and love Final Cut Pro X: if you really don’t find the Magnetic Timeline “works” for you then Final Cut Pro X probably isn’t going to be for you. That’s fine, I like the idea of choices in interface as it’s not something we’ve had before: Final Cut Pro 1-7, Premiere Pro, Media Composer all were based on the same metaphors (and in fact two of the three originated from the same mind.)

I definitely still have features I’d like to see in Final Cut Pro X – at the top for me is selective copy and paste attributes – but now that the major elements are in place, I’m sure we’ll see those features getting some love in the future: by implication we’re likely to see a couple more releases this year.

So, I say, love it or not (and I love it enough to plan on using it for a complex reality show under tight conditions this year) Final Cut Pro X is ready for prime time again, while acknowledging that it may not be for everyone. But now we have good viable choices, something we didn’t have before. I also believe we have a faster alternative that suits my edit style, but that remains to be quantified.

Yes, it works. It does an amazingly good job of translating Final Cut Pro 7 Projects (Bins and Sequences) into a Final Cut Pro Event. Clips from a FCP 7 project become clips in FCP X, Bins become Keyword Collections and Sequences are translated to Compound Clips, which can be:

• opened directly in a Timeline; a
• added to a new Project as a Compound Clip;
• broken apart to make a FCP X Project.

It is true to say that it’s the highest fidelity translation possible; it’s simple to use and it’s only $9.99 in the Mac App Store.

So what happened between September 22nd – when I wrote all the reasons why we weren’t making a 7 to X product – and now when we’re releasing one? As I wrote then, I always had the impression someone was working on it: either Automatic Duck or Apple. But it all went quiet. So, if no-one else was working on it, then we sure would like to. We knew from Xto7 for Final Cut Pro that translation was possible. (Turns out it’s harder going forward than back.)

So we approached Apple to find out if anyone else was working on it, expressing our interest in making it happen.Unlike almost any other Final Cut Pro X development, converting the XML seemed like a good third party opportunity. It turns out the opportunity was open, and Apple were very happy to work with us because of our understanding of XML. Of course it’s Greg Clarke who deeply, deeply understands the FCP 7 xmeml format and had already more experience than almost anyone else with the new FCP X fcpxml format. Apple graciously gave us both their blessing and early access to the 10.0.3 release, so we targeted that for the translation tool.

I’ve often said, in the last few months, that I would not want to be the person developing a Final Cut Pro 7 to X translation tool. I was telling the truth because I could hear the salty language that came from Greg’s work area: there’s no sugar coating it, this is the most complex piece of software we’ve ever written, and yet it’s the simplest to use. (Drop FCP 7 XML on app icon. Done.)

Along the way I learnt a whole lot more about Final Cut Pro 7 as I translated the video functionality from app to app. (Greg then translated that into computer code.) There are things in FCP 7 I never knew existed. There was at least one missed app opportunity! I also learnt that, indeed, these were two very different applications, with different data structures and two very different design mindsets. Translating from one to the other is difficult, in part because the new app was designed without thought for backward compatibility, which is entirely reasonable. Focusing on backward compatibility would bind the new app with legacy thinking.

I’m very proud of what Greg and I have achieved because the finished result is so much better than we ever thought it could be. I knew we could make a useful translation – definitely better than “cuts only” – but how high we could make the fidelity between the two versions, I just didn’t know. There are some things lost in translation, as a perfect translation isn’t possible between two very different languages. (Imagine translating Spanish into Mandarin, when you natively speak English and you’ll get an idea.)

You can find a full list of how the translation works at the Assisted Editing site, but some highlights for me are:

• Automatically converting PICT files to high resolution TIFF files because FCP X does not support PICT files.
• The idea of using the Timeline Index’s To-do markers to report any substitution from the original FCP 7 Project.
• Using Compound Clips for Sequences creates an Event structure that is very similar to FCP 7′s Project. Each “Sequence” becomes a Compound Clip in the FCP X Event, grouped in a Keyword collection “FCP 7 Sequences”.
• Using Roles to report the original track numbers: this is metadata and I would not allow it to be lost.
• Translating, as best as possible, the intention of the track usage in FCP 7 into the Magnetic Timeline required some intelligent interpretation of the original track structure into a FCP X context.
• That we do not lose any log notes, even though they don’t map well to Final Cut Pro X’s data structures. They’re all there in the Notes field and searchable in FCP X.
• We fully support translation of multi-cam projects from FCP 7 to FCP X.

There’s a lot of other great stuff that it does: audio and video filter substitutions; transition substitutions; all Motion Tab settings are translated, and so on. About the only caveat is that the media must be online throughout the export, translation and import to Final Cut Pro X process.

If you’re moving from Final Cut Pro 7 to Final Cut Pro X then 7toX for Final Cut Pro is going to be your new best friend. Even if you’re just feeling your way, 7toX for Final Cut Pro will also work with the free trial version of Final Cut Pro X so you can check out how closely translated your Project will be before upgrading.

Oh, and why is it so much cheaper than Xto7 for Final Cut Pro? Because we wanted to make buying it an easy decision while balancing out the enormous amount of effort that went into it (seriously, it’s dominated the last 6 months of our lives).

This led to the following exchange (transcribed pretty much verbatim) starting at 21’26 into Part 2′s video:

BEE OTTINGER: I think time is – there’s just not as much time. That’s the bugaboo all of us have. It’s the Avid. The greatest thing in the world is the the Avid. I wouldn’t go back for anything, but it.. it… other people had more to say because it was easy to change. The ease of change you would think would make things more creative because you could try things and it isn’t that great.

DEREK MCCANTS (Editor Big Brother): I would agree.

BEE OTTINGER (Music Video): Time?

DEREK MCCANTS: Yeh, and because of that in reality there’s less ownership for the editor. It used to be that an editor would do an episode. Now there’s three or four editors – maybe five – are working on the same episode to get it done.

ANDREW SEKLIR (Editor Battlestar Galactica): And I think part of that is when you’re cutting on a Moviola it had one picture track, usually one soundtrack that was kind of keeping going. Now they expect you to have a completely temp’d version with every sound effect, leading to “I didn’t like the way that computer beeped”. We get these kind of notes from network. “I don’t like the ring of that cell phone.” And you go “OK, maybe that’s valid but it’s a temp mix”.  But also with music and everything and that adds on.

It brings up two “modern” pressures that were not part of the traditional editor’s life (pre democratization of video): the lack of time, and the expectation that the “rough cut” will have music, temp effects, etc. The pressure is on the editor (and assistant) to go much further toward the finished piece so that the network or other approver won’t have to use their imagination. (Of course, that’s the producer’s failing and their response to be giving notes on temp effects indicates that the production skills of the executives, or their understanding of their industry, has fallen.)

I’d like to address both, and suggest why I think Final Cut Pro X is heading down the right direction. (Seriously, stick with me for a minute.)

I haven’t been using Final Cut Pro X on a huge project (yet, check back with me late next year) but I follow a lot of people who are and they universally comment that Final Cut Pro X is “200 to 400% faster” for them. As near as I can tell these people are doing the same sort of work on Final Cut Pro X as they were on Final Cut Pro 7 and finding that they get to a result from twice as fast to four times as fast.

Twice as fast to four times as fast!

Apple understands the pressure that’s on all production folk – be they working in “Hollywood” (the metaphoric one) or in the wider world of production – need to produce faster but with a higher quality product. So they designed with the following goals in mind:

• Avoid workarounds
• If we can automate and make something faster, we will
• Keep the quality at its highest possible level
• Be fast and fluid.

Now, I’m not going to argue that Final Cut Pro X as it is at 10.0.2 is a perfect solution for everyone.  The lack of support for layered Photoshop files, and no selective copy or paste of attributes still get in the way for me, but they’re interim issues.  Rather than looking at what the current release might lack, I’m more interested in how in-tune with modern production needs across the spectrum of editing, not only for broadcast television or film editing, Final Cut Pro X really is.

Back in June I wrote about the process of creating Conquering the Metadata Foundations of Final Cut Pro X:

What’s interesting is it parallels what seems like a design philosophy behind Final Cut Pro X. From what I’ve done in Final Cut Pro X, it seems to me to encourage a much more polished project along the way. It’s as easy to add an animated, high production value title as it would be to add a placeholder to remind you to do it later, as I’ve always (previously) done.

With the way clips (and titles) stick to other clips, I feel we’re encouraged to add polish as we go, by making it no extra pain to add the polish: a little color touch up; maybe a reposition; animate some clips. These are all so easy in Final Cut Pro X that I have to think this is part of the design philosophy.

What’s that got to do with the book? Every other book I’ve written or attempted to write, the draft was written in a Word processor and careful track had to be kept, with strict formatting guidelines, of what images were being added later in layout. It’s not until much later in the process, after the text is finalized, that it goes to layout.

That process wasn’t going to work in this case, so as I wrote on my computer, I would have Apple’s loaner beside me, snap a screen shot with the built in tools that are not perfect but functional. Rename it, drag it to iChat and dropped it via Bonjour to my own laptop. Then dragged the imaged directly from iChat to Pages and into the layout. It turned out to be a very efficient workflow.

I consider that to be a core strength with Final Cut Pro X – the ability to polish as you edit is much more fluid than in other NLEs of my experience. When you already have a searchable database of music cues and fx sounds, ready access to an Aperture photo library (or iPhoto), and hundreds of pre-programmed titles and looks, it’s much easier to approach finishing-as-you-go, and therefore fill that demand of modern production situations.

Now there are times when I don’t want to think about anything but story, and that’s just fine too. Final Cut Pro X gets out of the way there as well when all the finishing options just disappear from the interface when not needed.

While that’s great and I see how it fits with the ‘demand’ to see first cuts that appear finished from producers and executives, it’s the reported speed increases that fascinate me and tell me – for that reason alone – Apple’s bold attempt to redefine the NLE (as I had hoped) will be successful. In September last year I wrote an article What Should Apple do with Final Cut Pro:

What if Apple – since they have to rewrite much of Final Cut Pro – decided to not just do a “faster horse” rewrite but rethink what the NLE should and could be? The first problem with making major improvements is that it will involve change and we know that no-one likes change: they want things to get better but never change! So if Apple are re-imagining Final Cut Pro, it will be unpopular with “the pros”, at least until they give it a try. (And I can probably name those who will hate it among my acquaintances.)

Well, I did get the part about “the pros” hating it! And that some would come around when they gave it a try, but it was in a following paragraph that I asked them to:

Rethink the Interface. Reportedly Apple were looking to hire interface designers for the Pro Apps as recently as May 2010. I presume they’re hired by now, but you would expect a redesign to take at least a year to 18 months.

They rethought the interface according to the philosophy outlined above – faster and more automated – and we have Final Cut Pro X.  Let’s assume that it’s only twice as fast as Final Cut Pro 7. Some of that is simply because of a modern foundation that drops any requirement for transcoding or rendering effects, and that’s shared with other modern NLEs like Premiere Pro, Vegas, Media Composer and Edius. But some is because of the way the interface has been redesigned.

I noted when I first started using Final Cut Pro X how fluid it all felt and I expect that’s driving the “it’s faster” meme.

The thing is, if we have one NLE that’s noticeably faster in use, that word will get out to producers and, guess what? Producers and executives like things done faster because that’s the direction they’ve been pushing. (Oh, and faster is usually cheaper.)  If a two week job can be done in one, if a one week job can be done in three days, then whoever is doing it will adopt the tool that lets it be done in three days, or they’ll be looking for other work.

Now, I hope that there will always be projects that value the careful deliberation of the editor, where time for contemplation and reflection on the edit is expected, but if the panel at the Editor’s Lounge are to be believed – and they are – then these pressures are already part of their life.

It seems to me that if getting to a cut faster – and getting to a more finished cut while you do it – are the realities of a lot of editors lives, then Final Cut Pro X has been designed perfectly for the modern, professional edit environment. Even if it’s not there yet, the design intention and production reality seem destined to make Final Cut Pro X’s market share increase, even among the pros. (They won’t like it, but twice as fast can’t be ignored, let alone “four times faster”.)

The discussion starts with a discussion of the release of Final Cut Pro X 10.0.1. We know what features are in this release and what else is coming in “early 2012″ but what will Apple do for Version 2?

Terence and Philip discuss Intelligent Assistance’s new release Project X27 for transferring Final Cut Pro X XML to Final Cut Pro 7 XML for use in Color, Soundtrack Pro, Premiere Pro CS 5.5, OMF export and beyond. This leads to a discussion about the various flavors of XML and the differences in data structures between the two versions of Final Cut Pro. The differences between the publicly available FCPXML and the internal AXEL XML format used by Apple internally and for the Automatic Duck OMF/AAF export from Final Cut Pro X.

We briefly discuss the Automatic Duck changes in that context.

Finally, some time has become available and we’ve been exploring what’s required and there’s a problem.

Right now Event Manager X will quit Final Cut Pro X; reorganize your Events and Projects as you’ve set in Event Manager X, then re-run Final Cut Pro X. We need to do this so Final Cut Pro X will recognize the changed folder status: it only checks when it starts up or when new drives are added. It certainly doesn’t like it when we move an Event out from under it while it’s running!! So we don’t do that.

The problem we’ve run into is that an App Store sandboxing policy – and apparently one that is rigidly adhered to – is that no application can quit another application.

So, that would mean that when you requested Event Manager X to make your desired changes, that we would put up a dialog asking you to quit Final Cut Pro X. We can detect when it’s not running and make the changes and then restart Final Cut Pro X on your behalf, but we would have to have you do that one step that we currently do for you.  We don’t like losing functionality, particularly anything that makes the app work more smoothly.

So, the dilemma is that the App store is absolutely the right place to sell Event Manager X (and Project Xto7 as well where there’s no issue) but we hate losing functionality.

So, what do you all think? App Store with a less smooth workflow/product, or keep the functionality and keep it out of the app store? We’d rather not do both – having one version on our website and another in the App Store – but it’s certainly a possibility, although how to make the differentiation clear is a problem. Our preference for our Final Cut Pro X related apps is to have them in the App Store only.

Let me know what you think in the comments.

I figured you could answer this question, one which has been knawing on me since I first saw the beta of MC6.0.  How is it possible that Apple, and Adobe had to rewrite their apps virtually from scratch in order to switch to 64 bit, but Avid didn’t?  Is MC6.0 really 64 bit?

It’s a really good question. When an application needs to move from 32 bit to 64 bit, there are many approaches, but one thing is certain: all the code has to be 64 bit, including any dependencies or plug-ins. By dependencies I mean where the application relies on OS frameworks or libraries, such as QuickTime or AVI or other OS level service.  All these must be 64 bit or the application can’t compile to 64 bit. So all three companies had some rewriting to do, but because of their histories it’s actually different for each app.

Even though Premiere Pro is the most modern app of the three (Premiere Pro, Media Composer and Final Cut Pro) having been completely rewritten ahead of the 2003 release, it still largely depended on AVI (Windows) and QuickTime (OS X) for media handling. Neither have been adequately rewritten for 64 bit: AVI because all development stopped in 1996 (the zombie format that will not die) and QuickTime because Apple decided to transition to AVFoundation for media handling in applications, after attempting a partial rewrite of QuickTime as QTKit in 64 bit.

So, Adobe decided to write their own media engine so they could go to 64 bit without the external dependencies. (Premiere Pro still imports and plays QuickTime media by use of a complex workaround.) Most of Adobe’s code is C or similar with only an OS level wrapper around the cross platform code. So it’s “true” Cocoa on OS X because the interface is a heavily subclassed Cocoa frameworks (subclassed to make it look like an Adobe app, in the same way many Cocoa frameworks are subclassed in FCP X for its unique look).

Avid also decided to rewrite all their code from scratch, but instead of one big hit, they have been progressively rewriting their code for the last  three or four releases, if not longer.  You can write the code and have it compile into a 32 bit application (MC before 6) and then when you have all the app ready in 64 bit, you recompile it into 64 bit. Avid did not need to radically change the application, although there are two very major changes from the original code base. Avid Media Architecture was Avid’s approach to the multiplicity of non-tape sources, and it was all new code ready to recompile to 64 bit when the main application did. Avid also appear to have changed their approach to hardware interfaces with Media Composer 6, integrating a hardware abstraction layer so that third parties can integrate with Media Composer without needing to make any changes to Media Composer code. (Previously the Media Composer code needed to be rewritten to talk to each piece of changed hardware.

Apple had to rewrite because their media engine – QuickTime – was only partially rewritten to 64 bit and was lacking most of what the Pro Apps team needed for a modern video application. The solution to the media engine was AVFoundation originally created as the media frameworks for iOS and ported back to OS X with 10.6.7 and Lion,  which is why FCP X requires 10.6.7 or later.

Adobe relies on its own proprietary media engine. Avid relies on its proprietary media engine.  Final Cut Pro  X relies on AVFoundation, which only exists on OS X and iOS and is very, very new to code to0. (This was the likely reason that broadcast video out was delayed, because they had to wait for AVFoundation to be finished before BMD, AJA etc could even start work on drivers no longer based on QuickTime.)

All are really 64 bit, but they’ve taken different paths to get there, as they had different needs.

Export Final Cut Pro X Project XML to a Final Cut Pro 7 Sequence XML.  Because the two apps are so different, a perfect translation is not possible.

What works?

Here’s a list of what happens during translation.

• Video clips and stills in the Primary Storyline become clips in track V1
• Audio clips in the Primary Storyline become clips in tracks A1 etc.
• Connected clips are added to higher numbered video and audio tracks
• Split edits (J/L cuts) are preserved
• Synchronized clips are supported
• Auditions are automatically “finalized”
• If optimized media (ProRes 422) has been created in Final Cut Pro X, Final Cut Pro 7 will reconnect to that instead the original media
• Constant speed changes are preserved
• The active/inactive state of each clip is maintained
• Blue markers become blue markers in Final Cut Pro 7; unfinished to-do markers become red markers; and completed to-do markers become green markers
• Roles are added to the clip’s Description field and Notes to the Log Note field
• Cross Dissolve, Zoom, Flash, Lens Flare, Black Hole, Flip, Page Curl, Ripple, Swing, Cube, Doorway, Squares, Star, Band, Center, Checker, Clock, Gradient, Inset, Letter X and Wipe transitions are substituted with equivalents; other transitions become Cross Dissolve; audio transitions become Cross Fades
• Titles become Outline Text titles containing the original text
• Generators become Slugs named after the Final Cut Pro X generator
• The starting timecode is maintained

What doesn’t work?

The translation from Final Cut Pro X project to Final Cut Pro 7 sequence isn’t perfect. Here’s a list of what gets “lost in translation.”

• Compound clips
• Multiple speed changes in a clip and keyframed speed changes
• Effects
• For titles, font, size and color information does not transfer*. Some titles with complex builds may have the text out of order in Final Cut Pro 7.
• Transition settings*
• Color, Transform, Crop and Distort adjustments*
• Audio levels and audio enhancements*
• 4K media files (Final Cut Pro 7 supports formats up to 4000 pixels wide)

* we expect to support these features with a future version of Final Cut Pro X

Please use Provide Feedback… under the application menu for bug reports, feature requests or support.

 Known Issues

Compound Clips need to be broken apart into their original items. The easiest way to locate your Compound Clips is using the Timeline Index. Select each Compound Clip and choose Clip > Break Apart Clip Items before exporting the project XML from Final Cut Pro X.

In some cases clips may import offline. In Final Cut Pro 7 select the offline clips and choose File > Reconnect Media…

In cases where there is not enough media to cover a centered transition, the transition will be shorter than it was in Final Cut Pro X.

http://assistedediting.intelligentassistance.com/ProjectXto7/

As for why we didn’t do FCP 7 to FCP X, I refer you to the end of my last post on the subject.

By itself, XML tells you nothing. It is a generic term that tells you as much about the content as having a “Text” document tells you about the content. As I wrote four years ago for KenStone.net XML stands for eXtensible Markup Language.  You may be familiar with another markup language: HTML, or HyperText Markup Language.  In HTML only the WC3 consortium can add new tags because it is not extensible. On the other hand XML is “extensible”, meaning  anyone can extend it to mean whatever they want it to mean.

And that’s true for every type of XML.  In the case of XML for editing applications, the XML represents the underlying data structures from the application. So, we have:

• Final Cut Pro 7 XML known as xmeml
• Final Cut Pro X XML known as fcpxml
• Motion Project XML files are ozxmlscene
• Premiere Pro file is XML in the PremiereData format.

Each one is XML, and there is zero compatibility between them.  The design of data in an XML file is called a “schema” and every variation of XML is a different schema. More on schema at Wikipedia. The best way to think of the generic thing that is XML is that it is like an alphabet: one that can display French, English, German, Spanish and a whole bunch of other languages that use that alphabet.

So the first takeaway is that every format of XML is different and incompatible. So we need to stop thinking of “XML” as having any more meaning than saying “QuickTime” without specifying the codec(s): neither has any useful meaning without the further detail.

So that brings us to the specifics of translating xmeml to fcpxml (FCP 7 to X respectively) or going from fcpxml to xmeml.  Jon Chappell did a great job of explaining the differences in his blog post, but the important point is that the XML must relate to the data structures that it is trying to represent.

So when we come to going from Final Cut Pro X to FCP 7 we are immediately struck with the fact that FCP X has Events (media) and Projects (timelines), each with its own XML file, while FCP 7 puts them all together in one XML file. Because FCP X and FCP 7 are so different it will be impossible to ever do a truly perfect translation, just as all other inter-NLE transfers lack full fidelity. Import FCP 7 XML to Premiere Pro and say goodbye to most of you metadata (all Master Comments are lost, in fact all but scene, shot, take and description are lost). Also say goodbye to all your tiles and expect only imperfect mapping of filters and transitions.

And that is between applications that are fundamentally the same (having both come, originally, from the mind of Randy Ubillos). Final Cut Pro 7 and Final Cut Pro X  are fundamentally different in ways both visible and not.

FCP 7 counts all time measures in frames; FCP X counts time as rational seconds.

FCP 7 rounds frame rates to 3 decimal places; FCP X uses rational time so frame rates will be accurate, not approximate.

FCP 7 has tracks with time down the track as the only deliminator: FCP works with relationships between connected clips and story lines.

FCP 7 Title are a mix of FXscript and proprietary Boris Calligraphy formats (hidden in the metadata); FCP X titles are Motion 5 templates with rigs published to FCP X.

FCP 7 uses bins for media organization (and subclips); FCP X works with metadata (keywords) for media organization.

The way the media file information is stored in the XML is very different.

There is no common dictionary between the two versions of XML. There’s much more difference than say between English and Spanish, in the vocabulary.

The entire structure of the XML is much simpler and, at first blush fcpxml seems to miss a lot of necessary information, which isn’t really needed.

And so on. This is just a quick list of the differences off the top of my head. Translating is difficult!

We had a lot of difficulty translating fcpxml to xmeml – trust me, Project X₂7 was not created in the two days from FCP X 10.0.1′s release to the announcement Wednesday night.  And we’ve got the easy conversion. Going from FCP 7 to FCP X seems to be much more difficult. For example, all FCP X title text is visible in plain text, so we can insert that to an Outline Text Generator in FCP 7. Not so anything in FCP 7 that uses Title 3D, Vector, Crawl or Random. They are hidden in the xmeml XML as a “private data block” only Boris knows. So any of those titles cannot give you more than what Premiere Pro conversion does: there’s a title there but we have no idea what was in it.

Effect filters cannot be translated either way because the effect architectures are just so different. FCP 7 applies filters directly to clips; FCP X’s filters are applied in Motion templates and published to FCP X. There’s no way to reproduce that in a translation.

Another way of thinking about why translation might be difficult is when translating between two languages where the culture is very different. I recall, during the year I spent in Japan as an exchange student, trying to make a pun in Japanese. This fell completely flat because the pictographic basis to their language makes the concept of a pun impossible.*

Similarly, the very difference between the “culture” that is FCP 7 and the “culture” that is FCP X means that there are untranslatable bits.

Going from Final Cut Pro X to Final Cut Pro 7 has been a total pain and we’re still only at about a 65% fidelity, by which I mean we bring in the basic edit, including connected clips, markers, todos, etc. Going the other way should be even more problematic and I wish whoever’s working on it “good luck” because they’ll need it.

* I am told that a pun in Japanese is not impossible. Apparently my language skills never got good enough, or it was just a really bad pun!

A summary of duration appears in the Timeline Index header.

Select a role and, as well as all clips tagged with that role being highlighted, a summary of duration appears in the header of the Timeline Index.

This allows you to take your FCP X timeline (Project) to FCP 7 or directly to Color, Adobe Premiere (and via dynamic link to After Effects) or other FCP 7 XML workflow.

Via FCP 7 you can then link to Soundtrack Pro (sadly Soundtrack Pro’s project format has never been published), to Motion 4, or to OMF output for ProTools.

We still have a little work to do, but right now we support most features: connected clips, primary storyline, transitions (currently all are replaced by a cross dissolve but we’ll do better than that before release) but any time we can’t accurately reproduce something we’ll tell you in a report.

Tonight I demo’d a Project with:

• Titles at the start and end
• a mixture of primary storyline and connected clips
• a mix of active and inactive clips
• large numbers of J and L cuts
• To do markers and regular markers
• Spot audio effects
• And limited transition support.

All transfer without problem.  Unfinished To Do markers appear as red markers in FCP 7, done to Green and the blue FCP X markers to blue markers in FCP 7.

Before the comments go crazy asking why we didn’t do the opposite, since that’s what every really wants, let me explain.  Back in my initial briefing for FCP X I asked about the transfer and got the distinct impression that someone was already working on it (perhaps even Apple, it was vague). We’re a small software developer and can’t run the risk of spending considerable development effort to discover that a better funded competitor will come out with a similar product and kill our sales. Imagine if we announced this today, and three weeks from now Apple releases a tool. Obviously we’d get no sales.

Doing this type of conversion too is incredibly difficult and from our experience going 7 to X would be even more of a challenge. I wish whoever takes it on the best of luck.  In the meantime, if you need to integrate Final Cut Pro X into some existing workflows, Project X₂7 will get you there sooner.

Apologies if you got the unfinished version of this post.  Early starts and long days teaching at DV Expo takes its toll.

Apple teases us with Audio Role metadata that seems to have no current use within Final Cut Pro X.

If you open the Info Pane and select the Info tab, you will see the pop-up menu in Figure 20.1. showing the Roles

One magic way for this to be useful would be as a solution to the missing audio output options. In the near-magic, near-future I expect that a future version of Final Cut Pro X will use this Audio Role metadata to route audio outputs. At version 1 Final Cut Pro X’s audio output options are very basic, and there’s improvement coming, for sure.

So you can imagine how excited I was to open Final Cut Pro X 10.0.1 and see that those fairly limited audio roles (no doubt implemented specifically to enable export to OMF/AAF) had evolved into not only customizable Audio Roles, but to have the same option available for Video clips as well. And a Title Role comes rolled in!

Display the role, or the clip name.

Commenter Andrew Richards nailed it! Second commenter Marcus R. Moore also called out a real need. Well in the new release, not only can you use Roles in a Project to enable or disable clips assigned that Role, but selecting a Role highlights all Clips in the Project that have that Role assigned (either Audio or Video). Marcus kind of also gets his wish, because there’s a new option in the Project View settings to display the Role on clips, as an alternate to displaying the Clip name. It’s a non-destrcutive toggle.

There can be different Roles assigned for Audio and Video on the same clip and Roles can have sub-roles.

When selected all shots tagged with B-roll highlight in the Project. They can be deactivated temporarily with a single checkbox. (click to enlarge)

In fact, I think the implementation of Roles in Final Cut Pro X really completes the metadata story, and makes the Magnetic Timeline more valuable.

Here’s some of the ideas we’ve been thinking of:

• Multi-language Titles. Each language is a Role that is applied to the Title. With a single click on a checkbox, all titles from a language set can be enabled or disabled.
• Identifying A-roll and B-roll so one can turn off all B-roll to see the underlying A-roll story.
• Being able to selectively turn on or off the tracks that make up the audio mix, because now we can not just assign a Role of “SFX” or Dialog, but audio could be tagged with a Role that was, for example “Background Farm noise submix”. When (if) Apple implement a mixer in Final Cut Pro X then those clips could be assigned a single fader by Role name. Much smarter than track number mixing.

Roles now appear in the Event Browser’s list view as an optional column. This also means they are now available as a filterable field in the Filters window, or for Smart Collections.

I think (i.e. my opinion) that Roles provide all the advantages of using Tracks as de-facto metadata by making the job explicit and allowing us to use that metadata in a Smart Collection.

In other Final Cut Pro X update news

I truthfully have been focused on only part of the new version – the XML import and export specifically – so that we can have a new product to be announced at LAFCPUG @ DVExpo on Wednesday night, so I haven’t explored the other changes too much. I did go through every menu and dialog to find differences, but I’m sure this is not comprehensive.

Xsan is now officially supported for shared storage. At this point it’s shared storage of Events or Projects, not shared Events or Projects. Each Event or Project can only have one user active at a time.

Trial version. Check it out for yourself without commitment or cost.  Apparently fully functional but time limited, so you can even finish something for yourself.

Improvements to Share with better movie export options (from memory)

API for camera manufacturers to add their own format support. So, if we expect or want Alexa RAW or R3D native, then those companies apparently will be stepping up to make it happen. Definitely an improvement though, because users should not have to wait for a Final Cut Pro X release in order to get support for a new format. The manufacturer can develop it themselves and have it available when their camera is launched.

This release was pretty much what I expected: XML and at least one other banner feature, a lot of tweaking and (presumably) bug fixes.  They’ve knocked off a good number of features promised in the earlier FAQ, and Roles are an adequate (I say vastly better) way of achieving the same goal as track layouts did.

So, it seems they’re on the right path.

UPDATE: Turns out there’s more to Roles than meets the eye. Not only can you enable/disable particular roles in the Final Cut Pro X timeline, but there are new export options. The Export Media dialog now has options for exporting “Roles as Multitrack QuickTime Movie”, “Roles as Separate Files”, “Video Roles Only as Separate Files” and “Audio Roles Only as Separate Files”.

UPDATE 2: Here’s the knowledge base article listing the new features and bug fixes.

Until that point we’d only done black and white printing, and it’s easy to proof what you’re going to get on a B&W laser printer. Not so with color. Color output wasn’t as common then as it is now and we didn’t get the first Kinkos until very late in the 1990′s, so we really only had one choice for our runs of 2-3 covers for each job.

This became a serious problem when – while developing a food product for my parent’s company during the period I managed it (in addition to my own two companies) – we needed a very specific purple on mockup packaging we were presenting to food buyers at the national department store chains in Australia. Cadbury – Australia’s biggest chocolate company – have always used a specific purple in their packaging, and had just spent several million dollars on a campaign that heavily featured this purple. Since the new product was a chocolate variation on a traditional English Christmas Pudding, having the purple match was beyond important. And we got blue-purple, and red-purple: seemingly every color except the one we wanted.

The Chocolate "Blast of Mouthwatering Bliss" had to match Cadbury purple.

The problem was, what we saw on the screen and what they printed were two entirely different images. Just like that, the print industry’s color management problems were now my color management problems. There’s nothing like first hand knowledge of the problem to appreciate the cure!

By early 1998 we were full on into publishing, with the release in February 98 of the Media 100 Editor’s Companion. By this time we had  learnt – although that particular output bureau never did – the joys and benefits of ColorSync. While the interior was done with xerography (i.e. photocopying) the color covers were done in Sydney by a direct-to-plate digital offset and we never ever had color accuracy problems with an output bureau that used ColorSync.

Every printed cover looked the same, and the same as it did on the computer screen when it was desgined.

ColorSync was the solution the print industry needed to deal with color consistency and matching. The challenge is quite significant when you consider that each device treats color slightly differently: they have different “color profiles” in ColorSync Profiles. What ColorSync facilitates is a color accurate workflow, also referred to as a color managed workflow.

The challenge in print is to ensure that a scanned image reproduces with correct colors on an RGB display and prints consistently on a wide range of types of printers (and size of output) in CMYK color. On computers the images are additive (three light sources) while on paper they are subtractive.  If you worked hard you couldn’t create a less consistent workflow.

And yet, for the last 15 years or so, this has not been a problem. Colors in Photoshop, Illustrator, InDesign, Quark, etc. are accurately reproduced in the final output despite the different color models, device variations, display variations, differing types of paper and even ink variations. This has been possible because of ColorSync, largely developed by Adobe and Apple but now supported on every platform and by all manufacturers of scanning or printing hardware.

What is ColorSync?

This I knew when I wrote recently on how ColorSync might be used as part of Final Cut Pro X’s color management, but from the comments it quickly became obvious that I was very uncertain about:

• How does ColorSync work with video files, and specifically
• How does Final Cut Pro X use ColorSync to accurately monitor color.

So I took it upon myself to start researching the topic. I very quickly discovered that, while there is a lot of information regarding ColorSync and printing workflows, there was really nothing about ColorSync and video short of an OS 9 era article on ColorSync and QuickTime, noting that we can add ColorSync profiles to QuickTime movies using Terran Interactive’s Media Cleaner Pro! (That really dates it. Neither company nor product still exist.)

I took the opportunity to ask my contacts at Apple some specific questions about how ColorSync works in Final Cut Pro X and then synthesized that with the best information I could about ColorSync in general to research what I found. What was also interesting is that, while ColorSync has been mentioned in the PR materials and demos, there has been no explanation as to how that facilitates accurate color. This is my attempt to redress that lack.

ColorSync is built on ICC profiles and the two  terms are interchangeable: an ICC profile managed workflow is a ColorSync managed workflow. Each device – scanner, printer, camera, monitor – has at least one ICC profile. In an oversimplified explanation the ICC profile tells ColorSync (or equivalent engine in Adobe’s applications) how this device’s color representation differs from the standard. In this case it’s the XYZ Profile Connection Space: a colorspace with a very wide gamut.

So, for a given scanner the ICC profile is used to create an accurate representation of the scanner’s result into the Public Connection Space (PCS from here on) and the display’s ICC profile tells ColorSync how to accurately display that PCS on that specific monitor for most accurate fidelity to the original image content data.

In simple terms each device tells ColorSync how that device’s files relate to the PCS either to convert to the PCS or convert from the PCS to a display or printer. This way, each display or printed copy is color accurate to the original file, despite variations in printers or displays.

Source to PCS to destination. From Apple's 2003 ColorSync in Mac OS X document.

Workflows that correctly follow this practice are known as Color Managed workflows.  (Check and see if you’re reading this in a color managed browser.) From that page:

This is happening BECAUSE your color-managed browser is reading each file’s embedded profile and Converting or Mapping them to your monitor profile for a theoretical display of True Color.

In practice, while you may have to set up Photoshop or some other tools, for the most part, like the color management in Safari demonstrated from the link above, it just happens. You’ll find scanners and printers install ColorSync (ICC) profiles for all the functions – a scanner/printer will have a scan-to-PCS profile, and a PCS-to-printer profile – and OS X uses them.  Earlier versions of the OS required some setup but recent (10.5 onward at least) have implemented ColorSync so it “just happens”. As long as each device has a profile, and files are tagged with the appropriate source ICC profile, color accuracy along the entire process is assured.

Color consistency in the video world

Meanwhile, it was easy to monitor video: use a calibrated video monitor. Connect output of your edit system to said calibrated monitor. If you were very particular about your video signal you connected Waveform and Vectorscope to the output as well, so you could really see what’s going on in the signal.

The accuracy of the color entirely depended on how good a monitor you put on the end of the chain. Now in a perfect world this would be a broadcast level monitor, calibrated at least once a year, that could be relied on. I confess, I never had one, even though I delivered a decent number of TV Commercials for national TV broadcast, and other content that went to air. The majority of my editing career, however, has been for non-broadcast purposes.

Even today, I support systems that do work for major studios and none of them have a broadcast grade monitor, let alone calibrate it. One system is finishing HD footage to a 10+ year old SD TV set of no particular brand. Another restoring historic footage works primarily with a decent (but domestic) Plasma display that’s distinctly off axis from the editing position.

I’ve set up movie edit stations that have monitored on a Cinema Display via an AJA SDI to DVI adapter (with CLUT); or to an LCD TV. In fact that device is doing in hardware exactly what ColorSync is doing in software. Now these movies were not graded on this system, just for editing so that’s probably fair. Another client working on a TV series  for Cable Networks, has only a broadcast monitor (JVC 24U) in the grading room; the other four bays all work with consumer LCD or Plasma.

JVC-DT-V24L is a low priced broadcast spec monitor.

Color fidelity required that the NLE made no unintentional changes to the signal coming in and ultimately the accuracy of color depended entirely on how accurately the specific display represented the colorspace it was attempting to represent. In SD that would normally be Rec. 601 and for HD normally Rec 709.

It’s up to the NLE software to convert colorspace from the different source profiles it encounters: not only Rec 601 and 709 in video files but sRGB or any of another dozen possible profiles for still images.

This type of monitoring – a conventional video output – allowed monitoring in the destination colorspace, but appears to be not part of Final Cut Pro X’s design, at least according to Matrox. So, how does Final Cut Pro X ensure color consistency? Of course, ColorSync.

ColorSync was implemented in QuickTime. Badly. Final Cut Pro 7 did not support it, instead working with it own color conversion/matching technology.

Final Cut Pro X and ColorSync

As I’ve discussed the important considerations for ColorSync are:

• The colorspace, which can be considered to be the equivalent of an ICC profile, must be known and accurate for the file (taking the place of the source device profiles in print workflows);
• The rendering engine must use ColorSync to convert from source to destination colorspace/profile;  and
• The frames must be converted for the desired output, be it a Cinema Display, SD 601 or HD 709 result.

This is exactly what Final Cut Pro X does.

As files are ingested, Final Cut Pro X will read any ColorSync information if the files are tagged with information about their colorspace. If it’s a QuickTime file that contains an explicit tag for color information, that is respected by Final Cut Pro X, Motion 5 and Compressor 4.

If there’s not an explicit tag, then Final Cut Pro X infers the colorspace from known information. For example DV files automatically imply either an NTSC Rec 601 colorspace or a 1280 x 720 or 1920 x 1080 file will be tagged as being HD Rec 709 colorspace. These are quite reasonable assumptions and yet another use of Inferred metadata in the Final Cut Pro X world. Beyond those examples, Final Cut Pro X will simply make an intelligent guess based on whatever information is available. Fortunately, image size and aspect ratio are very strong clues to how the source color should be interpreted (the purpose of tagging it). 720 x 576 pixel files are almost certainly PAL SD files and so Rec 601 PAL is reasonably inferred.

Generally it’s older files that have no useful information and require inferring colorspace, but since there really are so few colorspace choices for video, compared with print where each device has its own characteristics, the source ColorSync information is likely to be highly accurate.

I’m sure someone will take me to task on the fact that Rec 601 doesn’t fully describe the color profile because there is no primaries defined, but Final Cut Pro X uses other information in the file to determine which of the well know primaries should be associated with the file.

So we have source color profile information associated with the files. Now it’s up to Final Cut Pro X to ensure that the rendering is accurate.

For Final Cut Pro X and Motion Apple created a shared render engine, touted as the “Linear Light Engine” at the NAB Supermeet Preview but that branding seems to have been dropped ahead of release. This shared render engine uses ColorSync to conform an image from one colorspace to another. ColorSync creates the steps that are required for a specific transform and then assembles them into a series of GPU operations into the GPU processing pipeline. Or in simpler terms, it manages the transforms so the source image content is accurately represented into the processing space.

There is no assumption about the input colorspace at render time. ColorSync profiles were derived or inferred on ingest or come from the image file. Most processing uses the Rec 709 primaries with a linear (1.0) gamma, ready for the final stage.

The third point above, is that the render engine has to accurately prepare that processing space for the appropriate output. If outputting to a Cinema Display, then the render engine conforms the processing space so that the visual appearance on the Cinema Display will look like the image should be viewed. (This works well with the recommended gamma and color temperature for the display: 2.2 and 65oo K respectively.) For the most accurate results you’ll want to create a ColorSync profile for the specific monitor rather than using the supplied “generic for this type of monitor” profile that ships. You can use the ColorSync Utility for that, or a tool that reads values off the screen to generate the profile.

If you’re working with an HD Rec 701 file but request an output for DVD, then the 701 frames (and other graphics from their colorspace) are converted and output so they are correct for the Rec 601 colorspace of a DVD.

So Final Cut Pro X determines the colorspace (ICC Profile) of the source on ingest; manages color using ColorSync through the rendering engine and then uses ColorSync to make sure that the representation on the display – whatever type of display – is also an accurate representation.

Meaning, there is no need for an external broadcast monitor in the classic sense. What you see on a monitor that has a ColorSync profile, is an accurate representation on that monitor of the source colors displayed on a Rec 709 monitor. And you don’t have to do a thing to get the goodness!

Not convinced? Well, coincidentally the Academy of Motion Picture Arts and Sciences’s “ACES or Academy Color Encoding Specification” initiative is planning something almost identical to ColorSync, but specific to the needs of motion picture post production, particularly with so much digital manipulation and inclusion of digital elements. (Look for the heading “ACES: Academy Color Encoding Specification”).

Beyond Rec 709

While the ACES initiative is largely about colorspaces used in digital cinema, it should be pointed out that a “broadcast video monitor” would be no help for colorspaces other than Rec 709 (for HD). So if you want to work with, DCI-P3, also SMPTE-431-2, for example in a traditional NLE you’d be stuck previewing in the wrong colorspace.

With a color managed/ColorSync workflow, if you have DCI-P3 media, and the appropriate source ColorSync/ICC Profile (or colorspace definition,) then ColorSync in Final Cut Pro X would present an accurate representation of that source on the computer monitor.

Mixing any of these colorspaces into any one, and then outputting the appropriate colorspace becomes no problem when using ColorSync.

Conclusion

While it’s a significant change from traditional workflows, the approach taken by Apple with Final Cut Pro X is a better fit for what happens in edit bays outside the big studios, where the problem with early Final Cut Pro users wasn’t that they weren’t monitoring on calibrated broadcast monitors but that they were monitoring only on the computer display. How many times did I, and the other Final Cut Pro 1 pioneers have to remind people that the computer display is not an accurate representation of the video!

Well, 2.2 gamma on OS X (since Snow Leopard) and ColorSync have made that advice not only null and void, but downright wrong. With a ColorSync workflow, the view on the computer monitor, particularly in full screen mode, will be more accurate than using a consumer television as a display, with the sole exception of interlaced video output. If you’re delivering for web, for LCD or plasma screen (i.e. all currently available displays) the display is progressive. Produce and edit accordingly.

I don’t think we have broadcast video output from Final Cut Pro X, because we have something better that accommodates todays colorspaces and will expand to accommodate whatever the future holds as well.

A disclaimer. I do not have the equipment available to test this: I don’t have a broadcast monitor nor a system that could output to it via SDI or even analog. (I could do DV via Firewire, but really….) I am confident that the solution that solved my inconsistent print color issues is robust enough, with the right software design, to manage my consistent video image needs.

The purpose of monitoring video on a broadcast monitor is to ensure that we have consistent color accuracy from a known reference. The value of a ColorSync workflow is that we ensure that we have consistent color accuracy wherever its shown. It’s a superior choice that avoids the limitations and expense of the previous “standard workflow.” Instead of having to build in a single colorspace on a monitor, Rec 601 or 709 style, with ColorSync all wide gamut monitors can be calibrated (ideally with a colorimeter and on that specific monitor) and used as reference monitors.

Smart Collections can be dragged from Event to Event.  You probably already knew that, but it was new to me.

This is really useful. If I’m working on an ongoing project and create, say, an Event for each day’s dailies.  In the course of preparing that footage, I apply Keywords and Range-based Keywords, and have a set of Smart Collections that organize the material appropriately.

When I get the next day’s footage and bring that into its own Event (or each Episode’s footage into an Event) I can drag the Smart Collections across to the new Event and they’ll instantly update to the content in the new Event.

This also applies to Keyword Collections, but since they’re created automatically when you apply the keyword, I don’t see that being so valuable other than to save a few moments setting them up if you prefer the workflow that creates a Keyword Collection first then drags Clips or ranges to the Keyword Collection (thus applying the Keyword to that Clip or Range).

In this episode Terence and Philip discuss how the postproduction landscape has changed a month after Final Cut Pro X was revealed. How has the competition responded and how has the Final Cut Pro community has reacted. Lots of discussion on the launch and subsequent response to Final Cut Pro X, touching on every aspect of the release.

Why is there an emotional connection with creatives and their tools. Where do Final Cut Pro 7 users go? Who is really focused on NLEs in professional postproduction? Oh, and yes, Philip has new software for Final Cut Pro X (inspired by Terry in part).

It strikes me that we might really be asking the wrong question, or questions. It’s not so much what type of work you do, or what proportion of your time is spent doing it, or even the attitude one takes to one’s work – “professionalism”. In the context of talking about the relative suitability of tools, surely the question is on workflows and toolset?

As many have identified, and I don’t think anyone argues with, Final Cut Pro X is – right now – good for some workflows. Those acquiring to solid state, or from the limited range of tape-based digital support, and going out to the web, trade shows, into education etc, where the destination isn’t a traditional television screen, but some variant on a computer screen.

What Final Cut Pro X is not good for right now are workflows involving multiple cameras; workflows that require some external manipulation as has been done through Final Cut Pro 7′s XML interchange; workflows that require moving a Final Cut Pro 7 project forward, workflows that need broadcast grade monitoring… these are workflows that Final Cut Pro X doesn’t support right now, regardless if you would have used them once a week, or five times a day.

The toolset is different and won’t suit the needs of some people, while for others it will be more intuitive and fluid. Different strokes for different folks and having choice is good. The suitability of a toolset isn’t determined by how many hours a day you work with a tool: it’s determined on whether or not the toolset works.

This seems like a good time to – once again – remind people that a version 1.0 piece of software is interesting, and could be fun and profitable – but it should not be something you bet your livelihood, career or business on. Changing a toolset and workflows needs to be done carefully and strategically whichever way your decisions take you.

As for Final Cut Pro X, we know many of those things are going to change. For the new workflow and the new AXEL (Apple eXchange Editing Language) we know it is “within weeks” – i.e. the first maintenance release to fix the issues that show up after release when more variety of systems and workflows are attempted. While for multicam we know it’s coming from Apple but not when. I think we can also definitely expect some enhancement to the tools in Final Cut Pro X as it matures.

As an aside, I have to say I’m feeling just a little excited about (potentially) what replaces “Final Cut Pro XML” (or more accurately xmeml, which is the specific XML format Final Cut Pro 3 to 7 used). AXEL is a new XML format for sure, but to describe it as an “Editing Language” strikes me as being a bit grand for only an XML format.  Given there is strong evidence of “good to great” AppleScript support, and the new XML is being described as an “Editing Language” then I have very high expectations that the “XML replacement” will be also best-in-breed, a title that would currently go to the very, very scriptable Sony Vegas, where the scripting language allows third parties to significantly enhance the application (including in earlier times, adding a multicam feature if I recall correctly). My fondest wish would be that we get something similar with Final Cut Pro X: Apple provides a highly competent, fluid, modern editing tool for the majority of their customer base, and that third parties fill in the workflows that are less commonly used, but highly important to certain types of media production.

So it really is about the workflows. Those that are, or are not, supported by a specific tool. If my thinking about the actual “XML replacement” is even close, then the idea of a core application maintained by Apple, and enhanced in a wide rang of directions to fulfill less common, but important, workflows, or even customize the application for a specific workflow, is very attractive.

I rather like this take on the reaction:

Beyond that, the new FCP is supposed to be easier for people who have never done serious video editing before. Pros don’t care about this, of course. In fact, many don’t like the idea of making video editing easier and expanding the pool of people who can do quality video editing. Making a task or software easier to use both makes current users’ jobs easier but also lowers the barriers to entry.

The thing about many Pros is that they like complexity on some levels. They like the idea of being elite and doing something that very few people can do. Or, more precisely, doing something that very few people would put up with. Just look at how complex and ugly Bloomberg Terminals are to see how people and industries like using something that looks complex and hard to comprehend by outsiders. Wall Street veterans have resisted a easier-to-user, easier-to-learn, more attractive Bloomberg Terminal for years.

With Matrox’s announcement today of their monitoring solution, which confirms uncategorically that there is no “broadcast quality video” out of Final Cut Pro X, I had to rethink what I thought they were thinking!

First a little clarification. Larry Jordan asked me to summarize AirPlay. It’s still evolving from its initial incarnation as a way of distributing audio from iTunes to external speakers and audio devices, but it’s being expanded on iOS (and therefore eventually on OS X) to allow video to be pushed from your iPad (or ultimately laptop/desktop) to an AppleTV connected display. Apple have a fuller explanation available.

So, while it’s a cool technology it isn’t something one would use to accurately grade footage. Surely Apple couldn’t have ignored this. And they haven’t, I have.

What I have bene missing is one of those major bullet points in the Supermeet sneak peek and subsequent release: Colorsync. Colorsync has a long history as a way to ensure that the color on one monitor would accurately represent the color that would be printed. All devices have color profiles (essentially Look Up Tables – LUT – to adjust the monitor to ‘standard’).

How do you grade in Rec 709 colorspace in Final Cut Pro X? You calibrate your display to Rec 709 colorspace using Colorsync.

A nice explanation of how this works in Final Cut Pro X from Chris Kenny over at CreativeCow.net (Chris is responding to Clayton Burkart initially – that’s the italicized text):

[Clayton Burkhart] “No, what makes no sense is Colorsync for video output, because Colorsync is an RGB system which an I/O system bypasses.

So if you expect to actually USE Colorsync for video, that by it’s very nature precludes YUV.

This does not mean of course that you cannot HAVE video output at the same time, it only means that Colorsync in reality will have little or no relation to your true YUV video image.

The reason that I have pointed this out is to show that Apple has almost exclusively concerned itself with the individual who creates WEB content which is RGB, not the video professional who creates for television, film, etc.”

Anything that can be represented in YUV can be represented in RGB. There’s no quality penalty for conversion if you do so in a sufficiently precise color space… and FCP X’s engine uses high-precision floating-point processing. You know what other app processes everything in a linear floating-point RGB color space? DaVinci Resolve. Would you like to argue that’s also not capable of accurate color output? Because my experience screening stuff I’ve graded with it in DI theaters says otherwise.

YUV, in the modern world, is best thought of as an internal implementation detail of some deliverable formats. With the precision of floating point, there’s no reason it needs to have anything in particular to do with how processing actually occurs.

FWIW, I consider Chris’s Nice Dissolve blog one to read on Final Cut Pro X.

So, whether we monitor remotely via AppleTV and Airplay, or use an attached monitor, color accuracy will be maintained using Colorsync, not specific monitors, which are used because they have the advantage of a calibrated colorspace. That sounds familiar. Similar things have been done in hardware by AJA and Blackmagic Design who have converters that take and SDI signal and convert it to DVI while adding a color LUT to display “video” color on a “computer” monitor.

I needed to think more different!  Or pay attention to the big bullets in Apple’s PR!

Since apparently the next update is coming “in a few weeks” according to the FAQ posted by Apple and will include the workflow/updated XML I wonder why it was released on June 21? What comes to mind is that Apple wanted to make it very clear that Final Cut Pro X will run on Snow Leopard (and uses Snow Leopard technologies like Grand Central Dispatch), even as the company prepares for the launch of the next OS – Lion – in the middle of July.

I don’t think it’s co-incidence that the first update release appears to be timed for Lion. Before I get to the topic of the title of this post, a little context. As I wrote a while back in Why we want Final Cut Pro rewritten to Cocoa, when you program to OS specific frameworks you get a lot of benefits “free”. In fact, what happens is that Operating System upgrades often bring new features to existing applications, just because the OS changed, and the application was written to take advantage of them.

Lion, I think, is a very important update for Apple. I harmonizes their two Operating Systems to a much greater degree than before. For a better understanding of the harmonization, you’ll need to sign up for a free developer account and watch some of the WWDC 11 videos. (But note, like me, signing up for that will put you under NDA so neither of us can discuss specifics.)

It seems to me that Final Cut Pro X, although written on Snow Leopard and released so that it’s obvious that it runs well on Snow Leopard, is clearly designed with a look toward a Lion future. Right from AV Foundation – the underpinnings of the media engine in Final Cut Pro X – to the single window(ish) interface, to the autosaving documents.

So, I fully expect that a small update (or not even an update) to Final Cut Pro X on Lion, will give use two Lion features immediately: versioning and a single window interface, Lion style. The latter is clear in the way the window operates. The former, not quite as obvious but the versioning features comes automatically with Cocoa’s NSDocument in Lion.

Versions would go a long way to alleviating the issues surrounding duplicating Projects to lock off certain states or to perform versioning. (The issue is that render files are duplicated.) To be able to go back to any earlier state of a Project will be helpful. And thanks to Lion it’s a feature provided by the OS rather than added to the application.

So, that brings me to the topic. Final Cut Pro X does not seem to have the same architecture as Final Cut Pro 7 and earlier, where external monitoring “hooks” were in the app for third parties to link to and send signals out to standard video signal formats – Component analog or SDI (or HDMI). AJA has announced a Final Cut Pro X solution that is effectively a mirrored desktop. Many find this unsuitable for color grading because of quality issues.

My first thoughts were that Thunderbolt equipped broadcast monitors might be a solution, but last night it struck me that the solution was really obvious and totally OS dependent but would give Final Cut Pro X a “real” video output: AirPlay.

AirPlay has been expanding under iOS to include video features, and it’s my expectation that it will also come “back to the Mac” with Lion although it’s not an announced feature that I can find.

So, Final Cut Pro X gets an AirPlay output option in Lion so that the video and audio can be streamed wirelessly to an AppleTV (hocky puck version) and now theres a real HDMI connector with the signal from Final Cut Pro X’s Viewer. For SDI there are HDMI to SDI converters available from AJA, Blackmagic Design and others. (Sorry if this blows a nice big surprise Apple has cooking for us, because this would be an amazing feature.)

And that’s how the Operating System solves a real problem for Final Cut Pro X.  I wonder if there are solutions at the Operating System level for sharing projects?

[UPDATE] I clarified and expanded my thinking on monitoring.