What Did We Learn?

It's X to 7. I don't think it steps on X2Pro too much, as it does't embed audio which is what many of us who send out elements to finish need. For me, the biggest hurdle to switching exclusively to X is the ability to exchange data with "legacy" systems. We mostly do offline, and Post Houses still require EDL's and OMF/AAF files as they finish stuff on AVID/ProTools etc. Having said that, X2Pro, with a couple caveats, solves the audio side, and the EDL side is pretty close to being taken care of as well. That will address one of the major complaints that "pro's" have about FCP X

BenB wrote:
Digital storage does not change every 5-10 years. I'm using the same SATA drives I was using 8 years ago.

I've consulted for Library Of Congress. That film storage costs money. There's 24/7 power to keep the environmental controls running. Media archiving is not setting a drive on a shelf, but storing it in active RAIDs that are also part of active production in most facilities. That film in sealed packs still can't stop the organic materials in film from degrading due to age. That happens no matter what.

You mention SATA (created 2003) which is a hard drive interface and which is not the only equation here. (The hard drive was introduced 1956 since then we had 8 interfaces numerous File System and data storage.)
I wonder what you have consulted? Why not use the environment sealed package where no energy is needed only a sealed storage vault?? Hey all I can say this guy is a export for Archiving 960 years old material! :whistle:

I think Film will have the same advantages for long time as does paper had and has...

But I guess we can go back to the topic... which is? :silly:

Well, we didn't learn about the schedule for any of the releases for the rest of the year (big surprise...). I'm interested to see if 10.0.6 takes the regular average of 70 days between updates, which would have it released in late August (closest date would be the 21st).

Since we've had two (barring Retina) maintenance updates in a row, I suppose it's possible 10.0.6 could appear earlier, but I wouldn't count on it. It seems the FCPX dev team have settled into a good, aggressive 2.5 month pattern. And if 10.0.6 is the big feature update many of us are thinking it will be, then they may need all the time they can get.

Editors hovering around the presenter at LAFCPUG were eager to know if the red camera support meant editing of native RED footage or just a seamless prores optimization. He was tight lipped about it, including the release date. I suppose it would be hard to announce a firm deadline, especially regarding a feature that Apple has to work closely with a third party to implement.

I would like to think the dual viewer will appear sooner than later, but I wonder how they will implement this? Undoubtedly, we'll be able to use the second viewer to preview clips, but I wonder if it will replace the current two up experience when trimming, or if it will allow us to see a before and after when color correcting, or view an image mask in one viewer, final correction in another, stuff like this would be useful. AppleInsider reported previously it will work like the standard source / record model.

Dual viewers could take up way too much screen real estate on Macbook Pros, esp. with a clip browser that never closes. I've sent in feedback to Apple to allow us to close the clips browser, but who knows. I already find myself tweaking the proportions of the FCPX interface too much than I would prefer to on my Macbook Pro. I like how I can already CMD+# target specific panes, like in all OS X apps, but I'd like to map Cnt+Cmd+# (or something similar) to specific workspaces for logging, editing, titling, color corrections, and audio. Like most editors, I just want to dive into what I am working on right now. Hopefully dual viewers will solve more problems than create them.

Multichannel audio editing may be the most useful update forthcoming, but will it help convert post houses and even get some audio engineer adopters? Hollywood is mostly ProTools, but I have worked at Post Houses that use Logic too. The ability to share FCPX events and projects is incredibly easy when you know the workflow, so if audio engineers can do most things in FCPX or roundtrip to Logic it will save both time and energy.

FCPX has an incredibly sophisticated audio engine at its core, including a lot of effects ported from Logic. The Channel EQ saved me yesterday when I had to make deadline using viewer submitted footage. It is incredibly easy to use, some of the best interfaces for audio effects ever. But mapping 5.1 is something left to be desired in FCPX, it is an incredibly time consuming task. I can see several advantages to including multichannel audio editing. I bet it will appear like the multi angle editor and may allow us to map roles to a track based layout or something similar.

If Apple gives us the ability to customize our workspaces again Dual monitors won't be a problem at all.

Yeah, after getting used to the single viewer I hope we are getting a cool active update.
Maybe a floating window or if it used for a preview viewer it sit in the Event browser.

But i really like idea using it for color correction or....

Yeah, after getting used to the single viewer I hope we are getting a cool active update.
Maybe a floating window or if it used for a preview viewer it sit in the Event browser.

But i really like idea using it for color correction...

" The ability to share FCPX events and projects is incredibly easy when you know the workflow,".

I would really appreciate your step by step approach to sharing projects and events. My own approach has been messy and anything but methodical. I would love to choose a method and stick to it. Any advice would be welcome. Maybe this deserves its own thread. Thanks.

Check out this video, explains it all really well.

Thanks Ben. That was really helpful.

Question about sparse images - do they compress the size of the events? I have a 2GB limit in drop box and I have pretty large events. I also tend to add pictures and often new footage to my jobs as I go along, as well as adding favorites which are in the event browser (also compound clips). That means when I share a project as I move through it, I often have to copy my events as well as my projects. Does it make sense to have one event per job? I developed a messy habit of having multiple events per job and ran into media linking problems. Thanks.

No, disk images do not compress anything. They are the size they are built to be. The only thing unique about a "Sparce Disk Image" is that it starts smaller than it's built to be. But when you create it, any type of disk image, it's a set size, like any hard drive. A sparce image will grow to it's full size, but no greater.

I make one Event per job, and use keywords, smart collections for organization.

Events are not something you'd send someone online. You'd ship a hard drive to them. All the footage is a ton of data. The Project "CurrentVersion.fcpproject" file is tiny and can be emailed or shared by other means online quickly and easily.

Both editors have to have identical Events on each workstation. Gather your material first, have your production planned, storyboard, etc. It'll make things go faster and smoother if you take time to plan it out in detail first.

Projects can be shared quickly and easily. Events are huge because they contain all the footage you've captured and logged. But Events can be still shared via the cloud. I've done it. On a 50 MB up/down connection, I recently backed up an entire 500GB drive to the cloud full of footage.

Shipping hard drives to people is quickly becoming an outdated way of thinking. With high speed internet and the cloud, we no longer need to ship drives.

installationspace wrote: Editors hovering around the presenter at LAFCPUG were eager to know if the red camera support meant editing of native RED footage or just a seamless prores optimization. He was tight lipped about it, including the release date. I suppose it would be hard to announce a firm deadline, especially regarding a feature that Apple has to work closely with a third party to implement.

The fact that they released the white paper only talking about rendering R3D to Prores is a bit worrying. If that is their view of 'native support' (which I would doubt very much) then I think I'll just upgrade to Adobe CS6.
I'm sure it will also have it sets of problems, but Apple was the FIRST company ever to get to give support to the RED camera when it was just released. It's now probably one of the weakest professional NLE options for working with R3D media and has been since 2009 or so. If they cannot give us a good way of native R3D support (even if it has a proxy mode built in ON TOP of native support), while other companies have been doing it for almost or more then 2 years now, I just don't know how to believe in FCP X anymore. I can wait for features to come, because Apple has shown that it does some things very good in FCP X (key wording, multicam, roles, ...) but the workflow their white paper suggests is already 4 years old or something. It's an eternity in NLE-land, and the competition isn't standing still either.

Hoping for the best...

I'm sure the white paper is to help folks out who need to work with RED today. But the native support is coming, just not this week. That seems to make a lot of sense.

Half of this is RED, also, who has to help write the plugin. Just like legacy FCP, FCP X import is a plugin architecture. It puts most of the responsibility of compatibility on the camera manufacturer. Personally I like this, because ever freakin' new camera has some freakin' new codec. It gets very hard to keep up with some times. But RED is one that has lagged on this. I appreciate that Apple is stepping in and taking up that slack themselves finally.

It's coming, along with lots of other stuff. Programing takes a lot of time to do and debug. At least we know the FCP dev team is in this for the long haul, and are serious about their work.

BenB wrote: Half of this is RED, also, who has to help write the plugin. Just like legacy FCP, FCP X import is a plugin architecture. It puts most of the responsibility of compatibility on the camera manufacturer. Personally I like this, because ever freakin' new camera has some freakin' new codec. It gets very hard to keep up with some times. But RED is one that has lagged on this. I appreciate that Apple is stepping in and taking up that slack themselves finally.

Not completely true. RED has been offering an SDK for years. Any professional software maker can step in and utilize it.
I know the Camera Import function of FCP X is a plugin architecture, but there's a difference between the Import architecture, and just having support for the codec.

www.red.com/developers

This signup is for companies wanting to integrate R3D file loading and decoding into their own software products on Windows, Mac or Linux platforms.

I can only hope that Apple's FCP X's implementation is very good and/or clever.

Apple is not a plugin developer, nor is RED. They both offer SDK's. I think that caused some problems. Apple seems to have expected RED to do it themselves like Sony, Panasonic and Canon did. RED was probably expecting Apple to do it themselves. At least something is being done.

My point originally was that Apple offered an import SDK for manufactures to build their own, Apple didn't want to chase new codecs on a weekly basis. But it seems Apple is finally caving in and doing it themselves now for RED. About time someone picked up the slack, no matter who it is.

It's all good news!

The thing I find funny is that R3D support in a realistic workflow is the exact same as it was in FCP7. I mean, did anyone actually try and use the R3D files in 7? Unless you had a rocket card, it was damn impossible to edit. Even then it wasn't great.

I've done the premiere edit R3D files natively and found my machine (a top of the line iMac that shreds most anything I throw at it) to be less than stellar. Maybe it's because I don't have the mercury playback engine because ATI cards aren't supported officially.

For my money, i'll still transcode to proxies (which is pretty fast) and edit my offline and online using Davinci Resolve Lite. It's a proven workflow, one that I am very comfortable with, and it allows me to edit a lot faster.

You try putting two overlay layers and a title track on an R3D file and tell me what kind of real time performance you get. My experience was unusable.

fcpguru wrote: The thing I find funny is that R3D support in a realistic workflow is the exact same as it was in FCP7. I mean, did anyone actually try and use the R3D files in 7? Unless you had a rocket card, it was damn impossible to edit. Even then it wasn't great.

I've done the premiere edit R3D files natively and found my machine (a top of the line iMac that shreds most anything I throw at it) to be less than stellar. Maybe it's because I don't have the mercury playback engine because ATI cards aren't supported officially.

For my money, i'll still transcode to proxies (which is pretty fast) and edit my offline and online using Davinci Resolve Lite. It's a proven workflow, one that I am very comfortable with, and it allows me to edit a lot faster.

You try putting two overlay layers and a title track on an R3D file and tell me what kind of real time performance you get. My experience was unusable.

I assume you are talking about the Quicktime Wrappers, the S, M and H proxies that referred to the R3D RAW Files, because you never could drop the R3D media in FCP 7.
I tried that, in both FCP X and FCP 7, and performance was indeed not that great. (S was okay, but still...)

I know that a native workflow isn't everything, but FCP X could have a great mix of being able to throw in R3D media immediately, and making proxies in the background IF you have it set up in your preferences. Best of both worlds.
And the fact that if you make an adjustment to a R3D file in RedCine, it carries over to Premiere automatically trough metadata, is very powerful and something I hope Apple will learn from.
(I don't know if it works the other way around too)
And the fact that you can access all the RAW tools in Premiere is great, for maybe a quick simple color correction (without going to Resolve - although maybe Resolve 9 will make some things easier, and is already a great program and an unbelievable bargain).
(ow, and Apple, please bring back the color wheels)

This is a maybe interesting thread from Mark Toia, an commercial director with a pretty impressive track record, talking about his experience of working with R3D media on a (Mac) laptop in CS6:

www.reduser.net/forum/showthread.php?797...-grading-on-a-LAPTOP !

That's what I mean with having good software handle the R3D. (I'm not talking exports though, I've heard they can be brutal in Premiere, but that being said: sometimes they are in FCP X too, because of the same reasons often - recompressing everything - although the issue is worse with R3D media).
BTW: Mark Toia works with Apple hardware too.

I've sent this to Apple as feedback as a benchmark for them to get their R3D support great.

installationspace wrote: Editors hovering around the presenter at LAFCPUG were eager to know if the red camera support meant editing of native RED footage or just a seamless prores optimization. He was tight lipped about it, including the release date. I suppose it would be hard to announce a firm deadline, especially regarding a feature that Apple has to work closely with a third party to implement.

Everyone think's their way is correct, but reading thru the REDUSER forums shows there's still a great amount of debate about whether a native R3D workflow is preferred in most cases. I think it's pretty obvious that if Apple has just published a Whitepaper on a transcoded RED workflow, then whatever they have coming up is going to be native in nature. That said, without a RedRocket card, you'll be in the exact same place as anyone working with a non-native format in FCPX (like h.264) you can do it, but you're always going to get better performance out of transcoded files. And what about when RED releases the Dragon upgrade later this year for EPIC, with 6.5K native size? Will that be supported? Working natively at these resolutions seems nuts in the short term.

installationspace wrote: I would like to think the dual viewer will appear sooner than later, but I wonder how they will implement this? Undoubtedly, we'll be able to use the second viewer to preview clips, but I wonder if it will replace the current two up experience when trimming, or if it will allow us to see a before and after when color correcting, or view an image mask in one viewer, final correction in another, stuff like this would be useful. AppleInsider reported previously it will work like the standard source / record model.

Dual viewers could take up way too much screen real estate on Macbook Pros, esp. with a clip browser that never closes. I've sent in feedback to Apple to allow us to close the clips browser, but who knows. I already find myself tweaking the proportions of the FCPX interface too much than I would prefer to on my Macbook Pro. I like how I can already CMD+# target specific panes, like in all OS X apps, but I'd like to map Cnt+Cmd+# (or something similar) to specific workspaces for logging, editing, titling, color corrections, and audio. Like most editors, I just want to dive into what I am working on right now. Hopefully dual viewers will solve more problems than create them.

I really hope that Apple doesn't bow to a traditional line of thinking here and simply reinstate the standard Program/Preview layout. Instead, I'm hopping for a much more contextual solution, like for trimming, so that you have an option for a clip preview or 2-up when appropriate, and not when you don't. Most of time it's just wasted space.

installationspace wrote: Multichannel audio editing may be the most useful update forthcoming, but will it help convert post houses and even get some audio engineer adopters? Hollywood is mostly ProTools, but I have worked at Post Houses that use Logic too. The ability to share FCPX events and projects is incredibly easy when you know the workflow, so if audio engineers can do most things in FCPX or roundtrip to Logic it will save both time and energy.

Apple needs to improve audio in 3 key areas-

1. visual organization. Roles need to be able to be organized in the Project timeline by grouping them together, or colour-coding them, or both.

2. audio mixing IN FCPX. For smaller jobs that are not going out to ProTools, we need to be able to assign Roles to sub mixes, and make mixing a more pleasant experience.

3. audio export to ProTools/Logic. While X2Pro may be filling a need temporarily, I really wonder if in the end FCPX will leave OMF/AAF to a 3rd party? Or maybe the thinking is backwards and ProTools and presumably LogicX will be able to import FCPXML directly the way DaVinci Resolve can.

Regardless, I think we're in for a BIG update for 10.0.6. Perhaps the biggest one yet...