[Erik Lindahl]

I did one bigger project in CS6 that ended up with either a corrupt project file or a project file pointing at bad media or simply PrPro CS6 being FUBAR. Either or I never got that project to work after about a week of editing. I had to rebuild everything in FCP7 to meet the deadline and I had a very embarrassing afternoon with the client when Premier got the above idéa to “die” on me.

All the media works in FCP7 – given I transcoded everything “properly” and converted all the image-files “properly” hence “bad media” was removed from the equation. I haven’t dared do any bigger projects in PrPro CS6 since.

[Erik Lindahl]

Nah, PrPro certainly can improve but I do see FCPX as version 1.0 and Premier as version 6.0 so I get when people complain about CS6 lacking stuff. I also get when people feel FCPX lacks stuff from it’s legacy (version 1-7). I also read “amazing” things about PrPro from I guess CS5 with it’s Mercury Engine and well it’s taken quite a few years for the magic to mature for mass-market. Prior to CS6 video output in conjunction with ME and / or ProRes was, frankly, useless in the program.

In terms of WMV licensing both Episode and Squeeze have sorted this out so I don’t think it would be that hard to fix if Adobe really wanted. I also gather, possibly, they’d loose X $ per OSX license then compared to Windows.

In that regard they should add ProRes support in Windows much like Episode has ProRes support here.

My primary system is still FCP7 but we are going to have to move somewhere soonish. Where, time will tell.

[Erik Lindahl]

I haven’t done any extensive tests on the area of export from PrPro vs FCPX vs FCP7 but I believe FCPX is far simpler / faster in terms of human interaction than PrPro especially now since you can set up custom outputs in the program quite neatly. It’s not optimal for batch-export but very “nice” for day to day use the times I’ve used it (and since the background process is automatic it’s much nicer than the somewhat daunting GUI PrPro shows us).

That said Compressor is more or less garbage. Lack of features, poor H264 encoder, limited MPEG2 encoder, no WMV-encoder (well AME is just as bad on the last point). AME is getting better and better but again this is an area where Adobe really should improve if their goal is to be a really serious player in the video-market. It’s actually here again a lot of silly human interaction “issues” they could fix quite easily. Batch-chainging how a series of files are interpreted is a lot of point > click > point > click. Here Adobe should look at how for example things are sorted in Episode Pro (give, EP is a buggy nightmare, they have gotten a few things right).

[Erik Lindahl]

We’ve in the same boat here. We do all our masters for broadcast in FCP7 still.

In PrPro you have to export each sequence manually per sequence. You can add them to a batch-list in AME but that oddly takes a lot of time per sequence one is sending out. In FCPX there is a similar issues, but the background-processing seems far most “instant” (and from my experience exporting broadcast stuff FCPX is much faster than PrPro or FCP7). A “backwards solution” is to add sequences to AME via AME but this again is quite slow compared to Batch Export in FCP7 or what Adobe already has in AE.

So the above involves more clicks and more human interaction waiting time which in our case is often worse than rendering times (as these even in FCP7 are relatively fast). And on my machine and the formats we work with (Uncompressed or ProRess QuickTime), the actual export in FCP7 is as fast as PrPro. As mentioned FCPX is far faster but FCPX has some quality issues in working with SD which makes it a less optimal choice here.

Again, on the flip side, I love the fact that PrPro allows me to edit image sequences and playback, for example, MPEG2 streams out to the broadcast monitor. I don’t however feel very “safe” in the application yet given our issues with either corrupt projects and / or the fact the program will accept corrupt media. Given the “all native” approach this potentially is a problem when dealing with less than optimal H264-files from unknown sources. Some kind of bullet proof validation-process would be appreciated here.

[Erik Lindahl]

To actually add something to the discussion:

Exporting of timelines in PrPro is quite bad compared to FCP (even FCPX from the little experience I have of it). The human interaction before you can actually achieve a batch-export is far from optimal. This could be part of the “more clicks than I’m used to” phenomenon. Why on earth Adobe hasn’t just implemented an AE-like export in PrPro is beyond me.

People can show rendering X frames in app A vs B vs C is Y% faster but sometimes dumb planning of an app actually makes the rendering part, for some work flows, not count that much. We output a lot of shortform broadcast masters and here FCP7 shines.

On the flip side PrPro shines in the fact it can actually play back the MPEG2 streams we send to the broadcaster. One just has to turn off the meta-data writing the CS-package does to files or they are seen as broken by the transport system we use.

[Erik Lindahl]

I do wonder who was “snark” in his comments. How do you know anything about my experience in the first place? I added a few lines of my experience to the discussion, given in a thread I don’t quite understand what it has to do in the FCPX-board, but never the less, I contributed something to the discussion. You… well yeah…

[Erik Lindahl]

And you are adding what your comment? I don’t have much more to say really. Reading Walters article this is a common issue evedently.

Am ruling out CS6? No, it could potentially be the king of NLE’s in my domain as we are heavy AE-users. But my few initial tries with the application have been rough. Versions prior to CS6 where slow and / or not usable for proper video monitoring (again, somewhat of a “known issue”) and now in CS6 things seem solid – great or amazing even – until we ran into a very nasty case of project courpotion.

And the “more clicks” is something I experienced also. For example I think FCP7 assumes a few things the editor wants that PrPro asks. This seems to be the case when setting i/o’s the viewer and timeline for edits.

[Erik Lindahl]

For me the best thing about PrPro CS6 is the “curroupt my project” feature not so many are talking about. When this happens and there is zero support from Adobes end it rings very bad from my PoV.

Regarding “many clicks” I’ve found the same in PrPro vs FCP7. I don’t have the concrete examples in front of me but I was struck by it on a project last fall.

[Erik Lindahl]

Can’t you do a match frame on the clip and do a replace / over write edit? Prior to doing this you could copy the clip if you need to paste any video-attributes back…

Not optimal but maybe a solution.

[Erik Lindahl]

Barefeats did some performance tests in Resolve yes:

https://www.barefeats.com/imac12p2.html

Seems the GF680MX is quite speedy after all.

I don’t however know exactly what you have to re-configure in Resolve to get it to work.

THE CUDA FIX
To get the Premiere Pro to recognize the iMac’s GeForce 680MX as a CUDA supported card, we edited the “approved” list in the app’s Contents folder. However, we also added it to the OpenCL supported cards list. Turns out that having it in both lists confuses Premiere Pro. When we removed it from the OpenCL list, Premiere Pro reported that it was using CUDA acceleration and the render times for Gaussian Blur and Fast Color Correction dropped. The same is true for the GeForce GT 650M in the Retina MacBook Pro. The graphs were updated accordingly on January 30th. Plus we added results for the GeForce G680 Classified as well.