APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

Re: FCP X features or lack thereof. Your opinion on the rationale.

COW Forums : Apple Final Cut Pro X Debates

Respond to this post   •   Return to posts index   •   Read entire thread

Tim Wilson
Re: FCP X features or lack thereof. Your opinion on the rationale.
on Nov 28, 2016 at 4:38:41 pm

[Michael Rooney] "To call it any kind of standard really is a stretch."

We'll take that for granted. LOL Thanks for your help in any case. 😀

[Michael Gissing] "If interchange is possible only via a new variant of fcpxml (currently in its 6th iteration) then it breaks all interchange."

Exactly the reason Apple should be out of the XML business. The less they touch, the better.

Thank the Godz (at least in their 1966-1973 iteration; pictured below) that QuickTime is less important over time. It was a running, not very funny joke that every time Apple used to update QuickTime, it would break FCP. Same for iTunes for that matter. New iTunes = busted FCP.

Not to overly pick on Apple. Many of the issues I describe here are endemic to many, if not most, host application developers. But this is a thread about FCPX features or the lack thereof, and my whole-hearted support for Apple developing less, and actively nourishing a third-party ecosystem to do more.

[Michael Gissing] " AAF, OMF AES-31, EDL etc. These standards may be legacy but they are still in use and a part of established workflows. "

The key to interop has been unchanged since Hippocrates: "First, do no harm." Even if it's not your standard, don't break it. Needless to say, this is all too rarely the case, and not just for Apple. Jay-z Louise, how often does a render blow out something as basic as timecode? Way too often, in every host, when it should happen NEVER.

So to be honest, the last thing ANY developer should have to worry about is keeping up with EDL or OMF support or whatever -- unless the host developer (Apple or anyone else) decides to get out of the way and neither support it nor try to replace it. That remains to me the best possible scenario.

[Michael Gissing] "Every time a new version of OS or NLE software comes out there can be a lag getting new bugs ironed out."

That's MORE true for host developers than third parties. BY FAR. Why? Because you know how many people at the host developer have time to give a crap as the main part of their job? FAR FEWER than at the third party!!!

See also my previous example of Apple Legacy breaking FCP Legacy with every new QT and iTunes release. Really, the only thing that anybody needs to know about FCPX is that this doesn't happen anymore. Sold! LOL

(Or does it and I've just missed those posts? In which case, just add it to the list of things I'm wrong about.)

In fairness to host developers, you can't just be throwing out releases willy-nilly, not even patch updates. For one, you have to create an installer and test the ever-loving shit out of it, which is insanely more work than you think.

I thought I had a pretty good idea of what this meant from being involved in release engineering at a plug-in developer, but when I got to Avid, holy cow, I had NO IDEA what was involved in developing a host-app installer. Beyond engineering, release engineering, and QA, the simplest of patches reverberates up and down every part of the company: documentation, sales, the web team, marketing, legal, on and on.

All of which implies that "not breaking third party plug-ins" is a priority, which, guess what.

OR [host developer name here] could just skip the whole megillah, let the third-party do the thing, and if there's a problem, the third-party is responsible for cleaning up...which they routinely do, often within hours of a bug report....which typically have more to do with something the host developer broke without even noticing, because host developers inevitably lack the development or QA resources to track all this.

Codecs really are a bigger deal than any kind of vfx. Think about how many codecs you've been waiting around for hosts to support over the years. It's insane. All any host would have to do to fix this is open the door and say, "Anybody out there got a better renderer than ours? Raise your hand."

That's one thing 3D developers get right for sure. Rendering is a function that CAN be farmed out, and IS farmed out. If FCPX would just hand off the rendering of camera codecs, you'd never have to wait again, EVER. The day you could buy a camera, you could use the codec.

Why not? Because host developers insist on standing in the way. It's been proven for generations (software-ly speaking) that other people can produce higher quality renders than the best hosts -- LET THEM.

ProRes is sort of a workaround of course, as was Avid DNxHD when it was released four years earlier. But they're both still bound by things like frame size, frame rate, definitions of what a frame MEANS, all that kind of thing, and annoying for files recorded in formats that ProRes doesn't support yet. Yet.

So the core function as defined today is, "We're the only ones who can render. You'll have to wait for us to support it, but our QA team is so small and so narrowly focused, that we may get to it, and we may not. And if you find a bug that we missed, you'll have to wait xxxx months before you can get the fix...even though the third-party camera or plug-in developer fixed it for us in 24 hours."

The core function as I'd LIKE to define it is "build hooks for render engines" -- which is well-established engineering -- and offer options for third-party codec management. Let the codec be 100% supported the day the camera is released, not because Apple has had to take their off the ball and rush out a new release to support the six maniacs who need that codec on Day One, but because the manufacturer has kept their eye on the ball, been test-rendering all along, and knows that their codec is render-ready on Day One.

Look, you may think codecs are a terrible example because ProRes has been handed down by The Godz (1966-1973 incarnation) and needs no improvement, and it is the duty of all mortals to bow down to The Godz (which I actually kind of agree with, vis a vis The Godz themselves anyway)...

....but the point is, I want every host developer asking themselves, every time, what's the LEAST we can do ourselves? What's the MOST we can do to support our third-party partners who are doing better work in these areas than we ever will?

Interop is a great example. How many DAWs in various configs do you reckon Apple has laying around for testing? The number is likely in the neighborhood of the number of people on the FCPX team who use DAWs enough to know what life-saving interop looks like.

No offense intended. Merely speculating. Nevertheless, Apple's never going to do as good a job as X2Pro or AATranslator or any other third party. Their time is better spent doing almost anything else.

[Michael Gissing] "I know the people behind AATranslator are constantly chasing such variables"

Of course they are, but that's life as a third-party developer. When I was at Boris, we supported 24 different host applications, and every one of them had different architectures, in some cases wildly so. I know Boris has added more hosts since then.

The thing is, you know how many people at [host developer name here] are keeping up with this kind of thing as their one and only job? Your guess is as good as mine, but it ain't many. Maybe none.

Which is why Michael, Simon Ubsdell, Boris, the X2Pro folks, and all of the many third-party developers who stand in the breach to meet needs that are no less life-and-death to me just because they're life and death only to me, are GODZ.

Which is why they should all wear their hair and dress exactly like The Godz. That would be awesome.

Posts IndexRead Thread 

Current Message Thread:

© 2019 All Rights Reserved