-
Screenlight: Will Accounting Woes at Avid Spark Big Changes or an Acquisition?
-
[David Cherniack] “It became theoretically and practically usable with the 5.0 64 bit re-write and Mercury playback engine.”
In 1998? That’s when Premiere (not Pro) was released. You might be thinking of Premiere Pro 5.
-
[David Cherniack] “[Chris Harlan] ” Wasn’t 4.2 when it became theoretically “useable?””
No. For large projects Premiere 4.2 was misery. It became theoretically and practically usable with the 5.0 64 bit re-write and Mercury playback engine.
David
AllinOneFilms.com
“Yes, I agree. We’re actually talking about Premiere and not Premiere Pro, back a billion years ago when the rumor went around by mouth and in print that it was finally “useable.” I don’t know of anybody who tried it, and had anything to do other than the most rudimentary of computer video edits, that thought it was worth anything. I think it was Premiere 5.0 where you could finally use 3rd party cards to get 30fps playback.
-
[Chris Kenny] “There is nothing about being a creative editor that inherently means one is qualified to comment about big picture industry trends, let alone that one is so uniquely qualified to do so that others should be silent.
“Chris, I should say I enjoy and value your input, even though I often disagree with your assessments. It DOES clarify things for me to understand that your day job isn’t editorial, and I now understand a little bit more about where you are coming from. I also understand the frustration Aindreas is expressing, because so much of what we are arguing here is about a maze that editors are running through daily.
-
[Chris Kenny] “You’re letting other NLEs define the feature set, and then pointing to FCP X and saying it’s missing features.”
I don’t think so. I’m looking for features expected by the industry to function in professional workflows. Things like proper project/media control, list interchange (AAF, EDL, XML), media management, interoperability within its own ecosystem (Motion, Logic), proper mixing tools inside the app and so on.
[Chris Kenny] “For instance, FCP 7 can export an EDL, and FCP X can’t.”
That’s not the only issue, but it’s an important own in the niche of high-end post. You of all people should know that, because I often cannot send anything other than an EDL to most of the top finishing/DI shops in the world. Why? Linux workstations and the ease of dealing with EDLs for them. EDL-X is a great little app, but I’ve had better luck going to FCP 7 via Xto7 and then generating an EDL. Ironically FCP 7 has become my “conforming” tool of choice when cutting on X.
[Chris Kenny] “I bet more editors want to work with native camera media than want to export EDLs.”
That’s completely true. I for one do not advocate using native camera media much. More often then not, it impedes creative editing performance when you need a fast and responsive system. But to that point, Premiere Pro and Media Composer support more native camera formats than does FCP X.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “I don’t think so. I’m looking for features expected by the industry to function in professional workflows. Things like proper project/media control, list interchange (AAF, EDL, XML), media management, interoperability within its own ecosystem (Motion, Logic), proper mixing tools inside the app and so on.”
The objective fact is that all of these apps have different feature sets. FCP X has features not found in other NLEs, and other NLEs have features not found in FCP X. Had you been using FCP X for years, and designing workflows around that, you’d be looking at other apps and saying they had workflow weaknesses because they required external transcoding, or they didn’t have metadata support as good as FCP X’s, or you couldn’t create bundles of output settings and generate multiple deliverables with a couple of clicks, or you couldn’t add roles to specific timeline items and output each set of items to a separate file, or whatever — all of these are features that could become critical to workflows one might construct around FCP X.
But since you’re going in the other direction, and dealing with workflows that were constructed around other apps, it’s FCP X that gets identified as having workflow weaknesses.
In 10.0.0, when there was fundamentally no way to get a sequence into or out of FCP X, one could say that there were, objectively, very serious workflow limitations. Now that we’re merely talking about e.g. the fact that FCP X requires you to use an external app to generate an EDL, but not to competently transcode R3D media, while in FCP 7 it’s the reverse, determinations about which app has the stronger workflow features are necessarily arbitrary and specific to particular situations and particular individuals’ sets of requirements.
[Oliver Peters] “That’s not the only issue, but it’s an important own in the niche of high-end post. You of all people should know that, because I often cannot send anything other than an EDL to most of the top finishing/DI shops in the world. Why? Linux workstations and the ease of dealing with EDLs for them.”
I recognize that EDLs are still necessary for some DI workflows — but not for all DI workflows. For instance, we ask clients for NLE project files (in case there are issues that are best fixed in the NLE before exporting anything), and in the case of FCP X would simply output an XML file and bring that into Resolve. Or, I’ve heard that Technicolor’s DI workflow involves conforming projects in Smoke — if they’re on the latest version, that means that perhaps the most ‘name brand’ DI facility in the world has the technical capability to conform from an FCP X XML file with no intermediate steps (whether they know this and would be willing to entertain the possibility, I can’t say).
So, even at the high end, a given project could, for all you can say in the abstract, end up finding (for instance) FCP X’s metadata features absolutely critical, and finding that its lack of EDL exporting isn’t a problem at all. FCP X’s workflow features have reached the point where one can’t say it’s worse with respect to workflow in the general case. One can merely point to specific workflows where it’s worse. But one can also point to other workflows where it’s better. Which makes it like pretty much every other tool in this business.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
[Chris Kenny] “Creative editors are not the only stakeholders who care about and influence outcomes in this industry. They’re certainly not the only people able to provide informed commentary about the industry or speculation about its future. In fact, while folks in this forum are, in general, reasonably engaged and well informed on the subjects surrounding this discussion, in my experience a lot of editors out there don’t follow industry ‘politics’, aren’t familiar with the history of computing or phenomena like commoditization (critical to understanding how the industry is evolving), don’t know anything at all about software development cycles, aren’t familiar with product development concepts like ‘minimum viable product’ (critical to understanding some of Apple’s decisions around the FCP X launch), and sometimes don’t understand end-to-end post workflows or just aren’t very tech savvy at all.
There is nothing about being a creative editor that inherently means one is qualified to comment about big picture industry trends, let alone that one is so uniquely qualified to do so that others should be silent.
But, hey, don’t let the fact that I predicted both that FCP X would be a radical departure, and the backlash to that a year in advance deter you from believing that I couldn’t possibly have the slightest insight here.”
Well said Chris.
Steve Connor
There’s nothing we can’t argue about on the FCPX COW Forum
-
[David Cherniack] “No. For large projects Premiere 4.2 was misery. It became theoretically and practically usable with the 5.0 64 bit re-write and Mercury playback engine.
“Which, for those who don’t know the history of Premiere, wasn’t the next version! David means Premiere PRO 5.0 which came YEARS after Premiere 4.2
Steve Connor
There’s nothing we can’t argue about on the FCPX COW Forum
-
[Aindreas Gallagher] “right, yes, well – we’re all lucky you’re here to inform us all at length on the the things we don’t understand, from your highly elevated perspective chris.
mother of god – I mean seriously.”
Well you did provoke that reply.
Aindreas is there ANY possible way you could just discuss the points that people make and not the people themselves?
Steve Connor
There’s nothing we can’t argue about on the FCPX COW Forum
-
in validating your opinion Steve, you have regularly referred to your experience as sometimes the entire basis for validating your point. you finish with – trust me, I’ve been doing this a very long time.
It is, I would say, fair to question someone’s arguments based on the fact that they are giving forth in an editing forum, without actually being, you know, an editor. I’m not the first person to raise this point.
https://vimeo.com/user1590967/videos http://www.ogallchoir.net promo producer/editor.grading/motion graphics
-
[Chris Kenny] “The objective fact is that all of these apps have different feature sets. FCP X has features not found in other NLEs, and other NLEs have features not found in FCP X. Had you been using FCP X for years, and designing workflows around that, you’d be looking at other apps and saying they had workflow weaknesses because they required external transcoding, or they didn’t have metadata support as good as FCP X’s, or you couldn’t create bundles of output settings and generate multiple deliverables with a couple of clicks, or you couldn’t add roles to specific timeline items and output each set of items to a separate file, or whatever — all of these are features that could become critical to workflows one might construct around FCP X.”
This is an absurd argument. You are treating these NLEs as if they existed in a parallel Universes, and that has no bearing to reality. In my country, everybody drives on the right side of the road. That’s our workflow. It’s been that way for nearly a century. All the lines and turn lanes are painted to facilitate that. All of the drivers muscle memory is all about driving on the right. All of the steering wheels and control panels are designed for driving on the right. Driving on the left presents an equally valid workflow. If we’d been driving on the left for nearly a century, our workflows would be constructed around that. But, so what?! Fortunately for X, it isn’t THAT different. But that is the argument you are making.
[Chris Kenny] “But since you’re going in the other direction, and dealing with workflows that were constructed around other apps, it’s FCP X that gets identified as having workflow weaknesses.
“Quite definitely.
[Chris Kenny] “So, even at the high end, a given project could, for all you can say in the abstract, end up finding (for instance) FCP X’s metadata features absolutely critical, and finding that its lack of EDL exporting isn’t a problem at all. “
It’s not Oliver who is speaking in abstractions. He’s speaking in practical terms. You are the one postulating a different reality to make everyday problems go away.
[Chris Kenny] “FCP X’s workflow features have reached the point where one can’t say it’s worse with respect to workflow in the general case. One can merely point to specific workflows where it’s worse.”
Sorry. “In the general case,” you CAN say which is worse, and taking the overwhelming numbers of real world examples and dismissing them as mere specific workflows is beyond cheeky.
Reply to this Discussion! Login or Sign Up