First reports on new FCP X rolling in - looks amazing!

[Mike P.]

The only reason I like native .r3d support is so that I don't have to waste time transcoding OR waste storage space having an second set of ProRes/DNxHD/Proxy files. In terms of storage, r3d raws are actually fairly light weight (given the resolution, colour depth, and raw). The debayering is what requires processing power, and that's what is finally getting mitigated… Whether at 1/4 or 1/2 or full res, the advantage is in not needing a second set of non-r3d files just to edit. It's been this way since CS5.5 mind you, but now everyone is on the same page performance-wise.

That said, I half-agree with Paul; things like libraries should have been there from the start and for serious audio work you need to rely on 3rd party software (that pretty much costs as much as FCPX does)… You can't even properly export to use tried and true solutions, which is kind of bunk. That said, for quick turnarounds, it's a pretty easy to go from camera-to-edit, which is something I appreciate.

 

[Sam Mestman - WMM]

We have been editing 2K .r3d proxies nicely in FCP7. In 2008.

Dude, you don't get it. Regardless, I'm glad you are able to work effectively. I used FCP7 too... for a very long time. I know enough to know the difference... but I really don't have the energy to do the back and forth with you. It's boring.

Andreas... any numbers I give you at the moment will be inaccurate... I realize that statement seems strange. I'll post something official once I get my official machine. I can verify that transcoding is substantially faster vs. an iMac or retina.

As far as RED taking advantage of the dual GPUs in the new MP, it doesn't yet. I imagine it won't be a long wait, though... and really, until that happens, no one is going to really know what the real specs are or what exactly can be done with red on it.

 

[Hrvoje Simic]

Dude, you don't get it. Regardless, I'm glad you are able to work effectively. I used FCP7 too... for a very long time. I know enough to know the difference... but I really don't have the energy to do the back and forth with you. It's boring.
.

I'm sorry if that parallel seems to you as I "don't get it".
Zero interest for a game of ping pong.

 

[David W. Jones]

In order to use this update, you also need to install 10.9, which I'm not ready to do yet, as other apps have issues running under 10.9.

 

[Mike P.]

I'm sorry if that parallel seems to you as I "don't get it".
Zero interest for a game of ping pong.

The proxies you speak of aren't raw. More over, the proxies created by the R1 (or in RCXp) aren't conducive to the workflow (they were merely a band-aid/workaround). The proxies you make within FCPX are directly linked to the r3ds; you can change the raw settings and FCPX will automagically re-create the proxies with the new raw settings behind the scenes without losing a step (or leaving FCPX… plus they're 1080p prores). It actually works excruciating well; the irony is you no longer need to use proxies at all, since FCPX (10.1 especially) can easily chew through r3d raw files in real-time (at 1/4+ debayer).

Hey Sam, do you know if FCPX, whenever the multi-GPUs of the MacPro are taken advantage of, will also leverage both the integrated GPU (Intel HD4000 or Iris) along with the discrete nVidia GPUs in MBP-Retinas? Obviously it wouldn't work as well as dual discrete GPUs (like the ones in the MacPro), but it'd probably give an extra 25%-33% (assuming the Iris is only 1/4 or 1/3 as strong as the 750m in the Retinas). I seem to recall someone saying that the whole point of the dual GPUs in the MacPro was that one would handle GUI/Graphics, and the other would almost expressly be used for OpenCL/General Processing. If that's the case, it *could* potentially be the same for Mavericks Macbook Pros with two GPUs (although to a lesser degree of prowess), no?

 

[Sam Mestman - WMM]

Well... the release notes just talk about dual GPU's in the new Mac Pro specifically... so my guess is probably not. This stuff isn't my strong suit, though... how would one go about testing that (I've got a retina) and seeing where performance is really getting pulled from?

 

[David Battistella]

I'm really liking the new library system as you can have one library per project. Key improvements are speed in the event browser. I've been cutting some stuff with 30 days of shooting and the event browser is very snappy. No real lag in the browser window.

i like that now in the library, the project timelines and the events are stored in the same place, more like what we have been used to in avid, fcp 7 etc.

when working wit red I always allow fcp to transcode the proxy files and edit the proxies. The proxies are 5k and are more than enough for screeners, etc in1080p.

The roundtripping with resolve works pretty flawlessly.

I do not miss having a mixer at all, because to reduce a "track" there are so many effective ways to set that up now (like using roles labeled track 1,2,3 etc) that a mixer seems a bit antiquated (and I am a person who is a complete stickler for audio even for the roughest cuts)

This update is just another step forward and the software has just gotten better and excels in so many areas. No looking back for me, but this just me in my facility and my workflow. I don'tdon't feel handcuffed dealing with any other aspect of production, vfx, etc at all, except for the OMF audio, but I use a third party software for that stuff or logic x for small stuff.

Battistella

 

[Hrvoje Simic]

The proxies you speak of aren't raw. More over, the proxies created by the R1 (or in RCXp) aren't conducive to the workflow (they were merely a band-aid/workaround). The proxies you make within FCPX are directly linked to the r3ds; you can change the raw settings and FCPX will automagically re-create the proxies with the new raw settings behind the scenes without losing a step (or leaving FCPX… plus they're 1080p prores). It actually works excruciating well; the irony is you no longer need to use proxies at all, since FCPX (10.1 especially) can easily chew through r3d raw files in real-time (at 1/4+ debayer).

Thank you for pointing out the differences. I appreciate it although that was really not necessary.


To avoid further assumptions suggesting the lack of understanding from my side...the parallel was meant to compare the benefits between prior and current solution.

Basically, compared to 2K .r3d proxy editing (using the same raw material and harvesting the benefit of wavelets to be able to work with lower resolution files without the need for transcoding) now on a much faster machines there is a possibility of editing full .r3d directly - but with 1/4 debayer, and the achieved benefit is ability to change raw settings while editing, and faster export of full quality material out of editing pipeline. I would use "NLE" but this is not a fully non-linear editor, for the reasons explained in the older thread.

In my experience practicality and freedom of editing are far more affected by full non linearity (i.e. multiple independent tracks, monitoring and bins within the same UI) than ability to chew through full quality raw files which need post anyway or the ability to change raw settings in the middle of editing process. Also, in my experience, most commonly editor and director work in tandem with material temporal "assembly", and colorist and DP on material's final visual aesthetic, and in that context these benefits do not seem that significant compared to what was lost from FCP7.

I do welcome the improvements though and hopefully they will not stop at "speed" factor.

 

[David Battistella]

Hrvoje,

I'd have to test R3d workflow on anew macpro to see how much the dual GPU is contributing to this real time r3d workflow, but even with a rocket on the previous FCP x versions i still was not confident editing r3d media. I get the spec saving argument, but it is a lot of heavy lifting when you get into accessing TB's of r3d material.

Its true rue that this r3d workflow has come a very long way since the start.

David