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

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