-
Remaining enhancements
-
You still are at the mercy of Apple. They tweak a spec in XML, it breaks something for the third party developer. So you may enjoy the tech support of the third party but they have to trust Apple to warn them of anything before publicly breaking third party software.
-
[Michael Gissing] “The 2 gig limit is only an issue if an OMF uses embedded media. FCP chose this methodology but it is quite possible to have a tiny OMF composition file and a separate folder with media file, none of which is likely to exceed 2 gig.”
I know and understand your point, and that’s fine if all of your audio is always spearate/double system. It’s not always practical as audio is embedded with QTs a lot in the case of fcp from either tape capture or tapeless sources.
I’d rather send a smaller embedded media file, but again perhaps that’s just me.
-
[Jeremy Garchow] “I don’t mind third party solutions. Things don’t always work, or something changes, or my workflow/footage needs a bit of customization. It is right here that having a small, responsive third party company to deal with shines, and shines brightly. Third party has always been a major strong suit with fcp, but maybe people don’t see that as a strong attribute. I don’t mind it, as I’m very used to it. Also, it is from these developers and workflow forumulists that holes and bugs within the underlying language of fcp get discovered and therefore squashed. Fcp7 would not be the strong app without the help of the above mentioned companies/people, along with the many others that aren’t mentioned… My view is that third parties made fcp better even if some people don’t realize it.”
[Michael Gissing] “You still are at the mercy of Apple. They tweak a spec in XML, it breaks something for the third party developer. So you may enjoy the tech support of the third party but they have to trust Apple to warn them of anything before publicly breaking third party software.”
I agree with both of these statements.
Interchange capabilities certainly improved from FCP4 (when Apple introduced XML) to FCP7, but FCP was pretty mature by version 4.
FCPX is young, and the data model is apparently still a work in progress (as evidenced by the changes between 10.0.0 and 10.0.3). Also, FCP Classic had the advantage of working in basically the same manner as every other time-based media platform on the planet. FCPX’s approach is unique, which adds an extra layer of complexity to interchange.
Once FCPX development is no longer a moving target, I think robust third-party extension will be reasonable.
All that said, I’m sympathetic to Simon’s point that Apple should handle at least some of this, too. EDL and OMF/AAF are not esoteric workflows; they’re table stakes for collaboration.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Michael Gissing] “You still are at the mercy of Apple. They tweak a spec in XML, it breaks something for the third party developer. So you may enjoy the tech support of the third party but they have to trust Apple to warn them of anything before publicly breaking third party software.”
This the way it’s always been. Remember when that QT/iTunes update caused all that pain a few years ago?
The third parties will be able to respond mich more quickly, and it is up to us to be smart users and make sure it’s safe to upgrade. It’s been this way since as long as I can remember.
Although not 100% reliable, some developers have early access as well. 7toX is an example.
Jeremy
-
[Walter Soyka] “FCPX’s approach is unique, which adds an extra layer of complexity to interchange.”
What seems to complicate this is that there’s no clear definition between audio and video clips and the nature of connected clips, primary storylines and secondary storylines. In the “standard” approach, it’s clearly defined what’s audio and what’s video and where they go onto either video or audio tracks. And each of those types of tracks have specific attributes and they are defined in the same way for all of the tracks of that type on a timeline.
FCP X breaks these conventions, so as you look at some of the various translation results, there’s often little rhyme or reason as to why clips are assigned to the primary storyline or some other place. At the moment, for better or worse, it appears that IA is really the entity developing those specifications. Hypothetically, if Boris came up with their own Xto7 or 7toX transfer tool, the resulting translations might look completely different from those of IA. That’s why I think it’s important for Apple to take responsibility.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “Hypothetically, if Boris came up with their own Xto7 or 7toX transfer tool, the resulting translations might look completely different from those of IA.”
But isn’t this true when going from any track <-> trackless (or layer) based system?
My fcp timelines look way different in AE. I know, completely different apps and uses, but same idea.
Fcpx’s timeline is unique, so the resulting translations might be unique as long as the stacking/layer order is correct, to honor correct playback/composite/nest/whatever.
Again this type of thing doesn’t bother me as I frequently use the duck to AE and the timelines are different, but my intent is still there in the two different environments (minus audio of course, so it’s not a direct comparison).
In pro tools, audio engineers frequently rearrange what I’ve done in fcp, but they understand my intent.
I haven’t tested everything, but my what I’ve sent 7toX so far, all of the intent is there, even if it looks different from my fcp7 timeline. As long as there are no glaring omissions (travel mattes/plug ins/things that simply don’t translate like some audio weirdness due to X’s weird audio handling), the timelines playback the same from both NLEs. And if they don’t, there’s a bit of clean up to do, but nothing horrendous when considering this was thought to be impossible on January 30.
-
[Walter Soyka] “…but FCP was pretty mature by version 4. “
Hi
4.1.1 actually, which came Dec 2003 after a NAB announcement/demo and summer delivery of 4.0.0, which was broken out of the starting gate. I think there were two or three further unstable iterations, before 4.1.1 which worked.
As FCP v4 was the first native OS X version it sort of paralleled FCP X’s 64-bit/AVF first-versionness.And actually in your golden-glow hindsightedness you are really referring to v4.5, which took over 15 months to arrive after the v4 announcement.
So what is going on now is just the same old same old, except all the noisy people were Avid then.
FCP editors stuck with v3.0.3 (OS 9) or 3.0.4 (OS X) for paying work because they were very stable, until 4.1.1 was seen to be working 😉 -
Really interesting post, Jeremy – which I have to say has made me change my mind to some degree. Andreas Kiel made a very similar point recently about how third parties pretty much invisibly helped FCP Legacy become what it was.
The only thing I would say is that it is very clear to say the least that FCPX is a very different more complex beast than Legacy ever was.
To use a car analogy (for a change – we used to get loads of car analogies but now it’s all baseball, baseball!), Legacy is like my old Triumph Spitfire that I pretty much took to pieces and rebuilt without being much of a mechanic because the underlying principles were so basic and accessible to a layperson. Conversely, with the modern car where everything is computer-controlled, you can’t hope for a non-professional to be able to do anything other than change the windshield washer fluid. Everything else requires you to go back to the dealership where they have the specialized tools and knowledge.
Legacy was fundamentally fairly simple and legacy XML made it relatively easy for third parties to build robust solutions. By contrast, FCPX is massively different to anything we have seen before and FCPXML seemingly still needs a lot of work. There is clear evidence that third parties are struggling, especially in the area of writing translators.
Phil Hodgetts I think said that writing the 7oX translator was like translating from English to Spanish via Mandarin, or something like that. That’s what’s of concern to me here. The levels of complexity are many orders higher than developers have been used to in the past and I think the ride is going to be rough for some time to come, at least in terms of translators.
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
[Paul Dickin] “4.1.1 actually, which came Dec 2003 after a NAB announcement/demo and summer delivery of 4.0.0, which was broken out of the starting gate. I think there were two or three further unstable iterations, before 4.1.1 which worked. As FCP v4 was the first native OS X version it sort of paralleled FCP X’s 64-bit/AVF first-versionness. And actually in your golden-glow hindsightedness you are really referring to v4.5, which took over 15 months to arrive after the v4 announcement.”
Sorry, Paul, I was very unclear when I called FCP “mature.” I didn’t mean bug-free, or even feature-complete.
I won’t argue your points on bug releases, but I will argue the arrival of major features. OS X support came in FCP3 [link]; while FCP4-7 may have been compiled for OS X only, they were still written against the Carbon API, which Apple introduced for OS 8 and extended through OS 9 and OS X. FCP Classic was never ported to Cocoa (OS X’s native API). XML was introduced in FCP v4, as I stated.
Rather, I was trying to say that the internal architecture itself was pretty mature and stable by v4, in the sense that it was apparently seeing more maintenance than redesign. Even by FCP7, you could still crash with a KGCore error, even though the product hadn’t been Key Grip since 1998.
This was a plus for third-parties, who had a stable platform to develop around, and a minus for Apple, who ultimately found it so limiting that they had to scrap it entirely and start from scratch with FCPX.
Architecture is important, and difficult. It needs to be stable (in the sense of unchanging) enough that others can develop for it, but flexible enough that it doesn’t bind your hands as you try to add features to meet unforeseen needs. You need to balance forward potential against backwards compatibility.
Look at Apple and Microsoft to see two different (but both valid) philosophies on this. Microsoft has historically prioritized backwards compatibility, lowering re-development requirements on developers, but also slowing innovation. Apple’s innovation comes at the cost of requiring frequent re-development, and Apple is very willing to pass that cost on to their third party developers.
Back to FCPX. It’s changed enough under the hood since its release seven months ago to spawn two releases of XML and break Automatic Duck. FCPX 10.0.3 definitely represents progress over 10.0.0, and with much progress still to be made, I’m not suggesting that Apple should slow down. I’m just saying that the product and possibly its architecture is in a period of very rapid flux right now and represents a moving target for developers.
This in turn passes risk on to users for critical and basic workflow features like interchange. That’s what I’d like to see a hybrid approach; let Apple take responsibility for the basic, industry-standard interchange fundamentals like EDL and OMF/AFF, but let third-party developers handle other workflow tools as Jeremy has outlined.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Jeremy Garchow] “But isn’t this true when going from any track <-> trackless (or layer) based system?”
No. Look at the placement of clips going from FCP to AE or Media Composer using either AD or Boris. The results are very similar, because there’s a common language. Not the case with X, because Apple has not defined the language of the translation. Therefore (hypothetically) one company’s translation results might be wildly different than another’s.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com
Reply to this Discussion! Login or Sign Up