[Keith Koby]

On the new Mac Pros and the new retinas in mavericks you’ll notice that there are no longer two sliders for monitor sleep and computer sleep in the energy saver settings. Instead there is only one slider for monitor sleep. There is a check box below where you need to decouple computer sleep from happening when the monitor goes to sleep.

This gave us some problems initially.

[Keith Koby]

[Jeremy Garchow] “Here’s hoping that developers will plug in to FCPX so that ref files won’t be as necessary?

I miss ref files, too.

“Export integration with third-party apps

Developers can plug directly into the Share interface within Final Cut Pro, allowing for seamless export to third-party systems such as Sienna, Vizrt, Primestream FORK, axle, and Cantemo Portal.””

I think that means exporting the file from fcpx and having a MAM be aware of it instantly. What John would want would be to export an xml and have episode engine read it like an edl and use it as a source.

Does the fcpxml point to render files? I’m under the impression that it does not. Otherwise, you could in theory convert fcpxml to edl and feed edl to episode engine.

I’m curious to see what they (telestream) have in store for nab.

[Keith Koby]

We haven’t found anything wrong with fcpx – just trying to master the new world of mavericks on the san…

As a matter of fact, we’re finding nice “bug” fixes. One huge issue for us in the past was the lack of text formatting information support in fcpxml in the past. Happy to see that fixed. It’s a great way to pass graphic builds between editors as a starting point for new projects. Making compound clips and distributing them in an xml is better than motion generator templates in some ways (contain audio and you can trim, not retime, trim compounds, and I don’t need to install the generator in ~/Movies/whatever…).

One thing I do miss is scrubbing through projects in the project library. I wish that “closed” projects could be scrubbed in their new event home.

[Keith Koby]

Yeah. This is where I expect the results to get interesting. We need to see the 8 core d700 and the 2 GB vram iMac. But the performance is pretty good on the laptop.

Render vs export. I always preferred turning off background rendering and trying to work realtime as much as possible. This is what I tell my editors to attempt to do. I’m really excited to see how the d700 does. However, there are definitely times where third party plugins won’t play back in realtime (some of the edge stuff for example) and you need to render it to see it.

For a bigger facility that turns out lots of material in fcpx, the time savings over a year or two makes the mac pro worth it. The retina mac book pro is a great choice for some based on that performance. The imac with the nvidia card is yet another great choice if you need Adobe performance as well.

I haven’t got to test an imac on mavericks and 10.1, but from a GUI responsiveness standpoint, the 6 core mac pro we have was much, much better than the ML iMac. This was on a complex project. I can’t wait to get an imac up to mavericks and 10.1 to see just how much of that is OS and software vs the hardware.

[Keith Koby]

You wouldn’t happen to have access to an i5 or i7 mac book pro or iMac for comparative purposes?

[Keith Koby]

I just did an export of an 8:12 timeline with lots of compositing. First I deleted the projects render files and then exported a master clip. 3:51 seconds, so better than 2x realtime to render and write out the file.

Later today I’ll try to get the original project san location open on an imac and do the same test.

[Keith Koby]

[Jeremy Garchow] “But that hasn’t happened yet, so for now, events seems like an unnecessary level of organization when getting footage and Projects between them seems “harder” than it needs to be.”

But if it does go there, it will be sweet, f’n sweet. And it will all make sense. 😉

To answer your original question; we bring footage into one event and import an xml of all the re-ocurring elements we use into a second event. So we end up with a footage event, an elements event, a “ratings” event for when we need to add mpaa ratings to movie promos and trailers and the such. That’s the way it happens now, and it seems like logical, nice, compartmentalized organization. You only import the xmls that you need…

So a library is like an fcp7 project and events are like bins I suppose. It is certainly an easier transition for editors to understand coming from fcp7 to x. Is that a good reason to keep it? I don’t know, but we use the separations now anyways. The episodic event separation makes sense though. If you need footage from the old episode, open the library and copy it over or keep an xml of the old episode footage on the network and bring it in to your new project…

I don’t see a problem with putting the projects in events. We had compound clips in them before and occasionally there were edits and editors that would make promo versions as compound clips rather than as projects in the old version of x.

I think from a program standpoint, database organization under the hood might be cleaner with lib/event organization rather than lib/wild dis-organization.

[Keith Koby]

[Andre van Berlo] “i’m also very curious how that 6 core performs! I’ve ordered mine also only with the D700’s. how much RAM did you configure?
“

Andre-
These 6 cores are the base configs with d500 and 16 GB ram and 256 GB storage. That’s one reason why they came so fast (because they were a true base config). I think you’ll be happy with the 6 core d700.

As for performance, I haven’t tested much yet, but from what I’ve seen so far I’m super impressed.

I upgraded one san location from earlier in the year. I intentionally grabbed a project that was giving us fits in probably 10.0.8 at the time. We were using maxed out fusion imacs and probably 10.8.4 at that point. The san location (about 78 GB) converted to a library in about 10 seconds. 10.1 gets really busy doing something afterwards, you can see the render meter going crazy, flashing to 100% very quickly. In the meantime, the application was super responsive. Playback was smooth. Renders (selections) were super fast. So from an unscientific, quick first look, I think people will be pleased with performance on the 6 core d500 base machines.

We also ordered several 8 core machines. Those we are waiting for.

[Oliver Peters] “I’d be curious to hear what sort of work and formats you are doing with this. Although the 8-core keeps getting mentioned as the “sweet spot”, it also has a slower clock rate. For HD output and ProRes, it sounds like your machine might be more than sufficient.”

Once we get the 8 cores, we’ll compare. But I hear you, the 6 core d500, from what I saw yesterday, might be plenty for ProRes 1080 formats (that’s the bulk of our work). Of course if the 8 core clobbers it, then the price difference is worth it for us because of the time savings over the 3 years or so that we typically keep computers in production. Also the 8 core d700s will be worth it if they handle the red files better etc.

[Keith Koby]

We got the 6 core d500 today Steve. I can test cs6 and cc on Monday or Tuesday maybe. We are busy re-outfitting a few rooms and testing 10.1 with mavericks on Xsan though…

[Keith Koby]

[John Heagy] “The edges are starting so round meaning less pounding into that round hole”

Agreed… Even though we (where I work) were already using it and finding it powerful and useful, it needed some intuitive organizational help. Thanks to people like you suggesting things, it is on it’s way to becoming more useful to bigger organizations. I appreciate your voice in the discussion John.

[John Heagy] “laughing at the emperor cowering naked in a corner”

oh boy… who lost their clothes?