Over the last couple of weeks, some of the discussion around Final Cut Pro X is focused on who Apple wrote it for – a discussion I’ve contributed to in more than one place. And I see today in Oliver Peter’s excellent review of Final Cut Pro X he tackles the same question and punts on “full-time” editor as the distinguishing factor. (And yes, yet another Final Cut Pro X post, but one where the main point isn’t really about that piece of software specifically, but relevant to the discussion.)
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.