-
DaVinci Resolve 8.1 — now with FCPXML roundtrip support
-
[David Lawrence] “But the EOL of FCS and the fact that Apple chose to name this new app “Final Cut Pro” inevitably means an entire industry that relies on FCS is now forced to compare the two and figure out what to do.
You may choose to use Windows or not, but FCS users have no choice. Moving forward over the next couple years, we either adopt a radical new UI or switch to something else. I guess a third possibility is that Apple reverses course and brings back an industry standard timeline option, but I think that’s unlikely.”
I still have a choice, and I’m an FCS user. FCS still works and is still on the market, although it’s been pegged to be put out to pasture. I have at last two other software packages that I can edit on my same exact hardware without changing a thing, actually three, PPro, M100 and Avid, oh and Smoke if I needed it, so four.
PPro, Avid and FCP7 have very similar methods, though of course not exactly the same. I don’t think it would take long. Of course there’d be some bumps, but them’s the breaks. Life is tough, truly. I am glad their are viable options. Ten years of technology is a decent run in this lifetime.
[David Lawrence] “Ironically, I also think your response to Windows is the perfect metaphor for what so many of us “haters” 😉 have been struggling with since June 21. Understandable, yes?”
Oh, heck yes. As I have said over and over again, Apple is asking a whole lot from us.
It’s really the first time in a very long time that I can remember, that Apple is asking a lot when it comes to interface. It keeps coming up how much people have to think before using this interface, usually Apple’s interfaces tend to do the opposite. They are intuitive, so easy they almost disappear, and of course they aren’t perfect all the time. This is an interesting new venture and I certainly don’t think it’s as dumbed down as people make it out to be.
Jeremy
-
[Jeremy Garchow] “All of these discussions have been great and has really showed me that despite some details, we really all want the same thing, it’s just we take different roads to get there.”
True!
I’ll state upfront here that I am not opposed to FCPXML, and that I understand that a new interchange format is necessary to take advantage of FCPX’s new features and data models.
My issue is this: FCPXML can be translated relatively easily one-way to older interchange formats like EDL and XMEML. If Apple had included this feature, FCPX could have fit into to many workflows at launch. Without it, FCPX had to BE the workflow.
I think my earlier comparison with XMEML was apt in this regard. EDL standards already existed, and Apple continued to support EDL input and output when they introduced XMEML.
XMEML was far richer than EDL and allowed much deeper integration with FCP. It took a little while, but eventually XMEML took root in the market for interchange with other apps, including Color, Resolve, the Boris translation utilities, earlier (and later) versions of FCP, Smoke, FCSvr, CatDV, and probably hundreds of proprietary workflow tools. EDL support was still there for those who needed it, but XMEML offered more functionality for those who chose to use it.
Then with FCPX, Apple decided to go it alone. They ignored industry standards and hit the reset button on interchange.
I think that getting an edit into or out of the NLE is an absolutely fundamental function. Imagine Word Processor X, an application that couldn’t open, print, or save documents unless you retyped them in WPX. Should the WPX developers leave it up to third parties to add basic I/O to the application?
The fact that Apple didn’t think interchange was important enough to develop for launch (or possibly ever, in the case of legacy import) suggests to me that “built from the ground up for professional editors” is just a catchy tagline.
Without interchange, you have to do absolutely everything within the app, or else you just can’t use it.
[Walter Soyka] “What should Resolve export in an EDL? Without meaningful support for file-based media, there’s nothing that Resolve ought to change from the EDL it imported. XMEML, FCPXML, and AAF all include broader media support, so there is meaningful changed data to get from Resolve there after a grading session.”
[Jeremy Garchow] “Why should it not? It’s a conform tool, ain’t it? 🙂 Is FCPXML not meaningful? Sorry, this is sort of meant as a joke.”
Hey, I included FCPXML in my “meaningful” section!
I fail to see what relevant contribution Resolve could make to an EDL. Nothing you do in Resolve should change the edit decision list. Shouldn’t all the outgoing source reels and timecodes be the same as the incoming ones? Changing anything there would destroy subsequent ability to re-conform.
On the other hand, XMEML, FCPXML, and AAF should be changed by Resolve so that they can point to the new media files that Resolve creates.
[Jeremy Garchow] “XMEML simply won’t work as well as it needs to FCPX. Since the whole structure has changed, the XML has had to change, too (you know have to describe an Event and a Project, just look at what happens when you import an FCPXML roundtrip from Resolve). They also “upgraded” a few things, as in true fractional frame rates. Finally. Yes, in order for other applications and workflows to work, they will have to adopt FCPXML.”
In order for other applications and workflows to roundtrip with FCPX, they have to adopt FCPXML, because Apple unilaterally changed the editorial data model with FCPX and offer no mechanism for importing legacy edits.
Any workflow where FCPX provides the creative cut and some other application finishes could have been accomplished with EDL/XMEML; the extra FCPX-only data that FCPXML carries could be discarded, since the other apps can’t use it meaningfully anyway.
[Walter Soyka] “This is a very interesting point. After Effects was never intended to be what it has become. The design philosophy behind most compositing apps (AE, Fusion, Shake, Nuke) is shot-based, so editorial information was never necessary.”
[Jeremy Garchow] “Never is a strong word, I think it wasn’t there because no one thought it necessary to figure it out (although I’m not saying it wouldn’t be tough). There have been many times I have wanted to send my sequence to AE from FCP7, do the work, have it render and then return in a sequence, just like Color does with tc/reel info still in place, just linked to new media. I can now do this with PPro, but it is a recent addition, and is proprietary to an Adobe workflow, sure it might not fit a feature film workflow, but I don’t edit features.”
Fair. How about “After Effects was not originally intended to become a finishing tool. It was designed as a shot-oriented, layer-based compositor that has organically accumulated a class-leading motion graphics toolset.”
Some things that are important in a finishing system are important in a shot-oriented compositor, too. You need immense control and quality. You need masking and tracking.
Some things that are important in a finishing system are just not important in a shot-oriented system, though, and that shows in AE’s design. No real-time, no editorial tools to speak of, no conform tools.
Could you cut in AE? Yes. Could you build a complicated composite or mograph piece in FCP7? Yes. Both are possible, but neither plays to the strengths of each application.
Stu Maschwitz and the DV Rebel philosophy have encouraged users to push AE into grading and finishing with AE, even though AE lacks the toolsets necessary to do either of these tasks efficiently.
To bring this back to FCP, I’d argue that conform is not a necessary tool for a compositor, but it sure is for an NLE.
[Jeremy Garchow] ” I would love this to be the model for FCPX. It doesn’t have a capture control window, that will now come from a capture card company. If you use Smoke, Avid, FCPX, PPro and an AJA card, you will be potentially able to use that same capture app across all the different applications. This, to me, is flexibility.”
I think we’re talking about different things here.
It sounds like you’re suggesting a separate third-party application that would handle all machine control and give you files that you can take to any application. That’s already possible today.
I’m suggesting that if FCPX were built like a platform instead of an app — if it were written more like a 3D app than a standard NLE — the capture card company could add a capture control window to FCPX. Deep integration like that could offer some really interesting benefits.
[Jeremy Garchow] “The market fragmentation is not going to stop, it is only going to get worse.”
But Apple is the one fragmenting the market here! Everyone else seems to value interchange — and Apple used to, as well.
[Jeremy Garchow] “I think in order to play nice with everyone, you have to delegate certain tasks to certain people, instead of trying to manage absolutely everything yourself. In my opinion, writing in EDL support at the application level is not a very good delegation of time for Apple. I do not think that they are skirting responsibility, I do not think that they don’t know what they are doing, I do think they tend to show you what’s obsolete before it’s obsolete, not that EDL is entirely obsolete.”
I think Apple should directly support openness in FCPX, both in data and plugin architectures. The more open FCPX is and the more different workflows you can plug it into, the more opportunities exist for developers around it.
It doesn’t take tremendous effort to play nice with everyone. That’s what standards are for. If Apple chooses not to follow them, they will build a very beautiful walled garden.
BMD had FCPXML interchange shipped less than one month after the FCPXML spec was published, and Resolve uses a standard timeline. Surely Apple, with all their resources, could have easily implemented EDL/XMEML output for the sake of interchange if they thought it was important. The fact that they didn’t makes me worry about their priorities.
Apple’s “we write our own standards” play with FCPXML-only interchange reflects what Apple thinks post should be, and that isn’t lining up with post reality for me just yet.
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 -
[Walter Soyka] “My issue is this: FCPXML can be translated relatively easily one-way to older interchange formats like EDL and XMEML. If Apple had included this feature, FCPX could have fit into to many workflows at launch. Without it, FCPX had to BE the workflow.”
I go back to my statement, the system wasn’t ready. It was released in the 10.0 state because everything was not quite in place. Apple knew exactly what they were doing. I believe that they knew this interface was going to be a stretch for some long time FCP users, they also knew there was going to be some bugs, they knew there was going to be some backlash, so instead of releasing it to an overwhelming majority of users who were going to bang on it harder than has been done in their “beta testing” FCPX would have been even more of a complete joke that some people think it currently is as it would have been full of half working “features”.
Let’s say they did release it, just like they did 10.0, except it had EDL and FCPXML from day1. Since they didn’t want to let the cat out of the bag early and give access to 3rd parties, not only would they have to chase down the crashing and display bugs, but then they’d have to chase EDL and FCPXML bugs on a system that isn’t even complete. They are finished before they even got started. The calculated roll out of features is just that, calculated. They are rolling this out “slowly” and I’m sure they are collecting data and taking notes, as the whole damn thing is not done! How can they begin to write in industry standard support if their own standards that they are hoping to get adopted (fcpxml, av foundation) aren’t quite complete?
Every other NLE/Color system is way more mature than FCPX, some of them by decades. For now it is sort of an island, and in my opinion was done on purpose, but who really knows that’s just conjecture on my part.
[Walter Soyka] “I fail to see what relevant contribution Resolve could make to an EDL. Nothing you do in Resolve should change the edit decision list. Shouldn’t all the outgoing source reels and timecodes be the same as the incoming ones? Changing anything there would destroy subsequent ability to re-conform.
On the other hand, XMEML, FCPXML, and AAF should be changed by Resolve so that they can point to the new media files that Resolve creates. “
Wouldn’t you want an EDL that connected to the new Resolve renders? Why go back to an NLE when it’s not needed? That’s all.
[Walter Soyka] “Fair. How about “After Effects was not originally intended to become a finishing tool. It was designed as a shot-oriented, layer-based compositor that has organically accumulated a class-leading motion graphics toolset.”
Some things that are important in a finishing system are important in a shot-oriented compositor, too. You need immense control and quality. You need masking and tracking.
Some things that are important in a finishing system are just not important in a shot-oriented system, though, and that shows in AE’s design. No real-time, no editorial tools to speak of, no conform tools.
Could you cut in AE? Yes. Could you build a complicated composite or mograph piece in FCP7? Yes. Both are possible, but neither plays to the strengths of each application.
Stu Maschwitz and the DV Rebel philosophy have encouraged users to push AE into grading and finishing with AE, even though AE lacks the toolsets necessary to do either of these tasks efficiently.
To bring this back to FCP, I’d argue that conform is not a necessary tool for a compositor, but it sure is for an NLE.”
So now that AE can be used for these things, that means it should remain the same and not get this interchange capability added? So, it’s grown or morphed into something that it didn’t start out to be. This is good!
And weren’t you the one saying that AE is THE example of an open and extensible system, when really, you must play by it’s rules and figure out the way to get in and out of it, and then mange that media, or buy third party plugins and use a proprietary linking system that’s owned by Adobe? At least FCPX now has FCPXML which we have already seen is talking to “industry standard” applications, and more will come. Shit, FCPX was already talking to AE, even without FCPXML which says something about both programs.
[Walter Soyka] “I think we’re talking about different things here.
It sounds like you’re suggesting a separate third-party application that would handle all machine control and give you files that you can take to any application. That’s already possible today.
I’m suggesting that if FCPX were built like a platform instead of an app — if it were written more like a 3D app than a standard NLE — the capture card company could add a capture control window to FCPX. Deep integration like that could offer some really interesting benefits.
“I think are talking about the same thing, different roads. 🙂
OK, so an AJA capture utility opens an application instead of a window in X, but what if it hooks directly in to X (or Avid or PPro, or Smoke)? What’s the difference? If the media is sent directly to FCPX in the background (which I think has been hinted at) what is the difference of opening a window or an app if it functions exactly the same? I used a separate app to aggregate all of my P2 data and I had the choice to either send it online (native MXF files) or offline (for batch log and transfer) and it allowed way more interface control than the log and transfer window does. It was all third party, and worked with FCP7 perfectly (via XML). I didn’t miss log and transfer at all, as a matter of fact, I loathed it and wanted every other media format to work just like I worked with P2 in P2Flow. I have seen the other side of true third party support and the attention and detail that is put in to something when they want it to work and work right. There was no way I was waiting for Apple to change the log and capture window, or the log and transfer window, or allow native MXF support. I went out and found other ways to do it and kept everything I liked about FCP7 working, but I didn’t need Apple’s help and I didn’t need to wait for very many features in order for it to work because Apple’s “platform” worked. I did need to wait for native AVC-Intra decode before I could use P2 Flow with AVC-I material.
I do not think that Apple needs to write in support for everything.
They do need to provide the basis of their own interchange language.
[Walter Soyka] “I think Apple should directly support openness in FCPX, both in data and plugin architectures. The more open FCPX is and the more different workflows you can plug it into, the more opportunities exist for developers around it.
It doesn’t take tremendous effort to play nice with everyone. That’s what standards are for. If Apple chooses not to follow them, they will build a very beautiful walled garden.
BMD had FCPXML interchange shipped less than one month after the FCPXML spec was published, and Resolve uses a standard timeline. Surely Apple, with all their resources, could have easily implemented EDL/XMEML output for the sake of interchange if they thought it was important. The fact that they didn’t makes me worry about their priorities.
Apple’s “we write our own standards” play with FCPXML-only interchange reflects what Apple thinks post should be, and that isn’t lining up with post reality for me just yet.”
I totally agree that Apple SHOULD be open, but sometimes they are not and never really have been. You have to do things their recommended way.
I think the interchange will come, they have a few more things to shore up first. They are basically telling us, it’s not ready for primetime without telling us in those exact words. Perhaps they should have said, “Everything just changed in post, but in the future someday. Maybe”. There’s no question this has been a marketing “disaster” or foul-up or whatever you want to call it.
It is pretty clear to me that Apple has thought about FCPX pretty hard, and they are still thinking about it. It’s not done, or else they would have released it. The whole picture is not in view, and some can’t wait for that picture to come clear. I get that.
I am looking forward to Lightworks, I hope it can fly, let’s see what an open source model can really do.
Sink or swim time.
-
[Jeremy Garchow] ” I believe that they knew this interface was going to be a stretch for some long time FCP users, they also knew there was going to be some bugs, they knew there was going to be some backlash, so instead of releasing it to an overwhelming majority of users who were going to bang on it harder than has been done in their “beta testing” FCPX would have been even more of a complete joke that some people think it currently is as it would have been full of half working “features”.”
Here’s what worries me most about this – this is the Wikipedia entry for iMovie …
iMovie ’08 (Version 7.0) was released in August 2007 as a part of the iLife ’08 suite. iMovie ’08 was a complete redesign and rewrite of iMovie.August 2007 (release of iMovie 08, prototype of FCPX) to June 2011 (release of FCPX) is almost four years – count them! Four years is a very long time in technology terms these days and getting longer with each passing year.
So here’s my question and no doubt it’sa very naive one. How come it has taken so long to get FCPX into shape given that it’s effectively been over four years in development?
And if it’s going to keep moving at this glacial pace what does that bode for the future, where its competitors are clearly now moving much, much faster? Adobe is now seriously cracking the whip and their ability to turn out breath-taking new image manipulation concepts is truly staggering. Does Apple really have it in them to keep up with this pace?
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
Thanks again for another quality riposte in this dialog.
[Jeremy Garchow] “I go back to my statement, the system wasn’t ready. It was released in the 10.0 state because everything was not quite in place.”
If FCPX were being built in such a way that was truly developer-friendly, then APIs and XML would have been ready before launch. I agree with you that it was not quite ready, but I’m worried that you’re underestimating how not ready it was.
Let me use a bad construction analogy. The user sees the finished house, but the developers work with the framing underneath.
The fact that the product is out but developer support is not suggests to me that they are are actually re-framing the house underneath the finished skin — or that developer support is not a priority. Either one is bad.
[Jeremy Garchow] “Wouldn’t you want an EDL that connected to the new Resolve renders? Why go back to an NLE when it’s not needed? That’s all.”
EDLs aren’t file based; they’re reel/timecode based, so there’s no need or way to connect them to the new renders. Instead, you can re-conform from the original EDL with the new render files (replacing the original media files) — if your NLE supports such old-fashioned interchange notions as EDL and conform.
[Jeremy Garchow] “So now that AE can be used for these things, that means it should remain the same and not get this interchange capability added? So, it’s grown or morphed into something that it didn’t start out to be. This is good!
And weren’t you the one saying that AE is THE example of an open and extensible system, when really, you must play by it’s rules and figure out the way to get in and out of it, and then mange that media, or buy third party plugins and use a proprietary linking system that’s owned by Adobe? At least FCPX now has FCPXML which we have already seen is talking to “industry standard” applications, and more will come. Shit, FCPX was already talking to AE, even without FCPXML which says something about both programs.”
I don’t want to argue against expanding capabilities, but this one seems like a stretch. You are suggesting essentially wrapping the entire functionality of Premiere Pro into After Effects, without losing any of what makes AE great.
AE isn’t an NLE. It’s not a real finishing system. It doesn’t have the necessary editorial toolset, because it’s not designed to be an editorial tool. The fact that it can be used so far outside of what it was designed to do shows how flexible it is, but you want to bend it more?
Another bad analogy: If an NLE like FCP is a hammer, a compositor like AE is a screwdriver. They are built differently, and built for different purposes.
That said, I actually did drive a nail with a screwdriver a couple days ago. I was on a ladder, and I had the screwdriver in my hand, so I gave up the appropriateness of a hammer for the convenience of not having to climb back down and up again.
If you want to borrow my screwdriver to pound nails, be my guest — but please don’t re-engineer it to drive nails better. I actually use it to drive screws, and rather like the way it works.
If anything, I’d argue that embedding AE in PrP would be a more natural fit: AE is built for shots, and PrP is built for sequences of shots.
Separate note: I would love to see Adobe take on Autodesk Smoke and Avid DS in the finishing market. They’ve got all the technology, spread out over a couple different applications. I’d love to see them take all those components and integrate them well. Dynamic link is interesting and can be powerful, but using it with AE and PrP shows the difference between a shot orientation and a sequence orientation pretty quickly.
[Jeremy Garchow] “I am looking forward to Lightworks, I hope it can fly, let’s see what an open source model can really do.”
Agreed. Should be interesting!
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 -
Oh boy. Here we go with iMovie. This is a faulty analogy as iMovie is not FCPX, but perhaps they used it as a testing ground of some of the ideas, and certainly borrowed some of the overarching ideas of the interface.
Smart Collections are like Smart Playlist in iTunes which was released in what, 2002?
So why has it taken so long for FCPX to be developed since obviously smart collections and smart playlists are so interrelated!!!!!!???????
I have no idea what Adobe’s going to do. It’s obvious they are serious, as any serious company does when they get serious, they start seriously buying up things, just look at Apple. They also now have star power if you want the ADR preview video that has been going around today. Star power seems to matter to some people in choosing an NLE.
I’m not discounting Adobe, they have a good thing going. I already use AE a lot and own PPro, I’m just not going to move there quite yet.
-
[Jeremy Garchow] “Oh boy. Here we go with iMovie. This is a faulty analogy as iMovie is not FCPX”
Sorry, but isn’t it a pretty well-established fact that iMovie was the seed product for FCPX? Are you saying there isn’t a continuous line of development from iMovie 08 to FCPX? What have I missed?
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
[Walter Soyka] “If FCPX were being built in such a way that was truly developer-friendly, then APIs and XML would have been ready before launch. I agree with you that it was not quite ready, but I’m worried that you’re underestimating how not ready it was.
Let me use a bad construction analogy. The user sees the finished house, but the developers work with the framing underneath.
The fact that the product is out but developer support is not suggests to me that they are are actually re-framing the house underneath the finished skin — or that developer support is not a priority. Either one is bad.”
Yeah, it all sucks. It’s not how I would’ve picked it. But here we are.
[Walter Soyka] “EDLs aren’t file based; they’re reel/timecode based, so there’s no need or way to connect them to the new renders. Instead, you can re-conform from the original EDL with the new render files (replacing the original media files) — if your NLE supports such old-fashioned interchange notions as EDL and conform.”
Yep.
[Walter Soyka] “I don’t want to argue against expanding capabilities, but this one seems like a stretch. You are suggesting essentially wrapping the entire functionality of Premiere Pro into After Effects, without losing any of what makes AE great.”
Mmmm, maybe? Why not? We have the technology. I have always wished AE was an NLE, it’s just not. I have always said that Motion should be wrapped right in FCP. Soundtrack Pro, too. Soundtrack Pro came close, but not all the way there. I am decently happy with the new audio controls, though. Parts of Motion are now in FCPX, I think it should just be the whole thing.
[Walter Soyka] “The fact that it can be used so far outside of what it was designed to do shows how flexible it is, but you want to bend it more?”
Hell yeah. If it makes my life easier, bend. That way I don’t have to bend as hard. Make the software work for me, not vice versa. Things, people, needs, technologies, ideas, they all change. These aren’t philips head screws and nails, as the Philips head screw is still a Philips head screw, a nail is still a nail. Yesterdays image creation processes are not todays image creation processes. I am not going to stick in the past of video applications, there are new requirements today, and I think the tools should reflect that, fragmentation and all. Just like an EDL, it was a tool of it’s time, and perhaps it’s time has come.
[Walter Soyka] “Separate note: I would love to see Adobe take on Autodesk Smoke and Avid DS in the finishing market. They’ve got all the technology, spread out over a couple different applications. I’d love to see them take all those components and integrate them well. Dynamic link is interesting and can be powerful, but using it with AE and PrP shows the difference between a shot orientation and a sequence orientation pretty quickly.”
They seem to be heading in that direction, let’s see what happens.
On another side note, check this out:
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Vimeo framework” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
[Jeremy Garchow] “On another side note, check this out:
https://vimeo.com/28962540“Wow. That is amazing.
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 EventsSome contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Vimeo framework” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
Because they share some of the same terms doesn’t mean they are the same program or even share the code, which means that FCP does not equal iMovie form the very foundation of it, even though they may look the same. Apple wants them to operate similarly to fit in to their systems and anyone that’s upgrading can learn the new system quickly, just like FCExpress to FCP7. The Creative Suite has made a lot of interface unifications as well.
Reply to this Discussion! Login or Sign Up