Re: DaVinci Resolve 8.1 -- now with FCPXML roundtrip support

At some point when reading this great post, I am realizing that we are more similar than different in our disagreements. 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. Thanks so much for keeping this going.

[Walter Soyka] "I use Resolve, so before BMD added FCPXML support, my options for conforming FCP edits were EDL or XMEML. I generally preferred the richer XMEML for interchange, but EDL was the lowest common denominator for getting the edit out of the NLE and into a grading session."

But it wasn't 100% necessary. Certainly a great option, and options are key, but an EDL to Resolve was not necessary. More on that later.

[Walter Soyka] "I call out EDL as the bare minimum standard for interchange. It's old, it's inflexible, it's naive, and it's woefully incomplete -- but it's still a good way to get the bones of an edit from one system to another. It's a lingua franca for editorial communication among apps.

Apple didn't include any interchange in FCPX at first, and when they added interchange with 10.0.1, they made it proprietary (though open). They ignored all the existing interchange standards (EDL, AAF, and now XMEML [which they themselves originated])."

Agreed, but it is for very very specific workflows. As has been mentioned, DI is one. That is one area where EDL is still used, and Red supports EDLs out of RCX and they are very important to them for film transfer. Broadcast deliverables is another that you mentioned, also extremely useful. I'll get to my point in a minute here.

[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."

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.

[Walter Soyka] "I oversimplified, but if I continued my oversimplification, yes, I would say that Avid does support Resolve. Avid is capable of writing industry-standard interchange files, which Resolve is capable of reading. The key here is "industry standard." Since both applications understand the same standards, no one has to do anything special to get them to work together.

FCPXML may well become an industry standard, just as XMEML did -- but XMEML earned its place in the industry by providing richer, more meaningful interchange, not by being the one and only way to interchange with FCP."

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.

[Walter Soyka] "See, I think that supporting standard interchange would actually make FCPX better generalized, because it would automatically work with anything that also supported the same interchange standards.

Apple should write and support standard interchange because they claim FCPX was "built from the ground up for professional editors" and because professional editors often need to move editorial decisions from one application to another.

Good interchange actually lessens specific demands elsewhere in the NLE. For example, with good interchange with a grading app, the burden on FCPX's color tools is lowered. With good interchange with an audio app, the burden on FCPX's sweetening toolset is lowered."

OK. So now we are back to FCPX as an application. Many many "complaints" from users (including me) was that FCP7's "finishing" tools weren't very good. Audio editing and filters were pretty crappy, I would use the 3way of offline/roughcuts, but that's about it. If going out to Color and DAW, I wouldn't worry about any of those things, I'd just edit, knowing we are heading for an external finish. Now, with FCPX, for the non external finish projects, which are happening more and more due to budget/time constraints, I now have tools that require zero round trip. This is a good thing. A very good thing. It makes my job much easier and I can go home to the family a bit earlier, and I can also "finish" while I edit. Of course, we will still do external finishes as well, so of course we will need interchange. I would rather Apple spend the time to get the tools operating much better in FCPX so I can save a little time, rather than work on an EDL exporter. I will gladly pay a third party for an EDL exporter. It's what they do, they will support it directly and if there's an issue, I can pick up the phone and talk to a human or get wicked fast response. This just won't happen with Apple. I personally don't need EDL, but I am saying for those that do. I do need interchange in the form of OMF and XML the elder for now, if and when applications I use decide FCPXML is OK, then I won't need XML the elder.

[Walter Soyka] "[Jeremy Garchow] "Here's why I think Apple hasn't let in very many 3rd party developers to FCPX. Very simply, the system wasn't ready."

That's what I'm afraid of, and it scares me.

Truly flexible and extensible systems are more like platforms than applications. The first-party developer makes their own tools available to third-party developers (like how Adobe uses the plugin architecture themselves to extend AE)."

I hear you. But do you really think it's not going to happen? Yes, it's unfortunate it wasn't ready all at the same time, but does that mean we will never see it?

[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."

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.

[Walter Soyka] "[Jeremy Garchow] "Is there really no history? What about fxplug? or fxscript before it? Or before that it was the AE script or whatever it's called?"

I didn't meant to suggest that Apple had no history of allowing plugins; rather, that they didn't build the sorts of large, flexible, extensible systems that would allow a third party to, say, add their own machine control to the application."

A ha.

Now this, this very idea, is exactly where I am heading. As of right now, 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. You have mentioned platforms, this is how I see FCPX, a new platform from which to jump off. Hopefully the hooks that are in FCPX are big enough and strong enough to support whatever workflow you choose, and yes, part of that specialized workflow might have to come from someone who is dedicated to writing it as it's in their best interest to keep it functioning. Apple sure isn't, and I am Ok with that too. Shore up the things that need to be shorn, like FCPXML, and make it as open as it possibly can so people can glom on to whatever they need out of it. The market fragmentation is not going to stop, it is only going to get worse. If third parties are allowed to participate (which once the OS/Application/Frameworks are ready, I am sure Apple will open the doors) the FCPX application is a step in a direction of tying to serve as many possible outlets as possible, which is a monster of a task. 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.