Thank you for the nice 6.5 upgrade

yes, Dear Apple

thank you for this 6.5.0 Fcp upgrade !

nice list of things we should have received like.. one year ago

and iChat theater ! ... my eleven year-old son is thrilled !

next time think about something many pros need, like: multicore rendering (... ?!)

maybe for Fcp 7 ? a real upgrade I mean

This sort of post doesn't belong here. If you want to send feedback to Apple, go here:

[www.apple.com]

Although they're going to want something more substantive as well.

(And for the record, Final Cut Pro has had "multicore rendering" for ages.)

We don't mind the occasional here and understand some of your frustrations, but this sort of post simply invites argument rather than discussion. And that translate into noise.

Michael Horton
-------------------

Every version we see the Negative Nellies come out. It will die down soon. I happen to think it's a solid release.

Kevin Monahan
Social Support Lead, DV Products
Adobe
Adobe After Effects
Adobe Premiere Pro
Adobe After Effects and Premiere Pro Community Blog
Follow Me on Twitter!

Seriously. The people who are griping about the magnitude of the 6-to-7 upgrade must not have been around in the 4.5-to-5 days.

I actually quite liked the 4.2-4.5-5 upgrades. They were almost all improvements, as far as I remembered -- 4.5's DVCPro HD support, 5's H.264 codec, etc. I haven't really needed FCP6's features, but I'm eager to get my hands on FCP7.


www.derekmok.com

This happens to be the best pound-for-pound upgrade to FCP since I did the crossgrade from 4.5 to 5.1.4. I am on the side. There are more pluses than minuses...and the ProRes update just rocks my world.

GREAT JOB APPLE!! Keep it up for the next major release!!

When life gives you dilemmas...make dilemmanade.

Not yet having used 7, I'm still of the opinion that 5-6 was a somewhat bigger advancement than 6-7 is. It was 6 that brought us both ProRes and the open-format timeline, and both of those fundamentally changed the way I work with the application. They weren't big, flashy changes, but they make things possible that previously had been impossible, or at least prohibitively impractical, or at least pains in the butt.

That said, I reiterate that I haven't used 7 yet. Back when 6 came out, before I used it for an actual job, I really wondered what all the fuss of the open-format timeline was. I mean, geez, I batch-convert everything to my timeline format anyway, so what's the big deal? The big deal, of course, being that I didn't have to any more, and I didn't see that until I had some stick time on the new system. So I might change my mind after putting in a few hours on 7.

The new ProRes codecs alone make this a major upgrade. That is for the Pros. Makes offline/online much more viable, and makes the offline/online tapeless workflow a great thing! As is the much needed Metadata import for P2, also a great things for the Pros.

The other stuff is icing...markers that move when you cut or insert edit...colored markers...iChat Theatre...OH...SPEED CHANGES ALLOWED IN COLOR! Huge huge huge.

And I am sure Apple says "you're welcome."


www.shanerosseditor.com

Listen to THE EDIT BAY Podcast on iTunes
[itunes.apple.com]

I'm interested in knowing more about multiprocessor rendering in FCS3.

Its not clear to me, now that we can "Send to" Compressor from FCP7 does that mean that I can use Qmaster and render a FCP7 project over multiple CPU's? There's a bit of confusion about this. At least I'm confused...

This seems to be an extremely common point of confusion.

Rendering and encoding are two totally different operations. Rendering is what Final Cut does to apply effects or filters, or to convert open-format timeline elements to your timeline format. Encoding is what Compressor does. Both Final Cut and Compressor can encode; Compressor does not render.

As far as I can remember, Final Cut has always had multiprocessor rendering. I could be mistaken, 'cause my recollection is quite fuzzy before Final Cut 4.5 on my dual G4 (which I still have in the closet with a dead power supply; sigh).

I highly doubt FCP has multi-threaded render ability...FCP's rendering ability has always been lame...which is why I prerender composites in After Effects or Motion which is light years faster then bring them into FCP.

When life gives you dilemmas...make dilemmanade.

well, i'm wondering what would happen if you leave your sequence un-rendered,
and then "Send to compressor"...

i'm wondering if the multi-threaded compressor will deal with the FCP renders?
although my guess is that'd be too good to be true.


nick

Quote

I highly doubt FCP has multi-threaded render ability[/i]

I promise it does. Check your Activity Monitor during a render sometime.

You win jeff. It's multi-threaded. But you know what? Rendering in FCP STILL sux jeff...always did...still does...no matter how you look at it. Multi-threaded or not.

When life gives you dilemmas...make dilemmanade.

Just as you gave me a lesson on the difference between rendering and encoding, there's also a difference between "multi-threaded" and "multi-processor."

I'm hoping to take advantage of all the mac pros and Xserve's we have and use Qmaster to distribute the entire project using as many processors as I can throw at it. FCP has had the ability to Export via Compressor for some time, although I don't understand what benefit there is to that since you can't use Qmaster to distribute the render. It also doesn't make sense that if I have an 8-core machine and it can use all eight, why can't it use 32 cores of a virtual cluster created with Qmaster?

When I export a two hour XDCAM HD sequence, it takes FCP five to seven hours to RENDER the Quicktime movie. I don't care if you call it rendering or encoding, it still sucks.

If you have to do this seven times a week at the same time color correct and continue to edit, well you do the math. FCP might be popular but it sure isn't industrial. They need to solve these kinds of latency issues. They provide a myriad of tools, any of which are awesome, but collectively its getting harder, not easier to make money on the scale required with FCP being the bottleneck.

It seems that some of the improvements in FCS3 are simply stupid human tricks that you might see at a trade show but not as useful as demonstrated.

Quote

Just as you gave me a lesson on the difference between rendering and encoding, there's also a difference between "multi-threaded" and "multi-processor."

Only in the most technical sense. Using multiple threads of execution is one way to use multiple processors simultaneously. Final Cut Pro uses a thread model, as do most applications. Compressor uses a different model because it's so tightly integrated with Qmaster. Different steps, same dance.

Quote

FCP has had the ability to Export via Compressor for some time, although I don't understand what benefit there is to that since you can't use Qmaster to distribute the render.

There really isn't any.

Quote

It also doesn't make sense that if I have an 8-core machine and it can use all eight, why can't it use 32 cores of a virtual cluster created with Qmaster?

It actually makes perfect sense. Computers are not magic. In order for Final Cut to run on a cluster, it would have to be written as a cluster application. It never has been. And for good reason; the amount of work necessary to abstract out the rendering module and replace the threading model Final Cut currently uses with a message-passing proc model would be huge, and it would provide no performance gains unless you were on a SAN. While there are a number of Final Cut sites out there that use Xsan or another SAN solution, there are vastly more that don't, so Apple would be investing thousands of man-hours in a feature that only a tiny percentage of customers would be able to use.

Quote

When I export a two hour XDCAM HD sequence, it takes FCP five to seven hours to RENDER the Quicktime movie.

Well of course it does. That's a workflow problem. XDCAM HD is a very heavy codec, and not suitable for native editing. It's just like HDV in that respect. In fact, from a technical perspective, XDCAM HD and HDV are basically identical, except it can go up to 35 megabits per second rather than being capped at 25. But both HDV and XDCAM are long-GOP MPEG-2 formats, and thus fairly difficult for the computer to decode, and monumentally difficult for the computer to encode. Basically when you render an XDCAM HD timeline, the computer has to fully decode and fully re-encode every frame on your timeline; this is only true of long-GOP formats, which is why people don't edit those formats. The bottleneck in your workflow isn't Final Cut, and believe me, Apple's not trying to piss you off by holding back some magical feature that will make everything work in real time. The bottleneck in your workflow is the fact that you're doing a @#$%&-ton of math, and your computer can only do that so fast.

I mean no offense, but if you're cutting ten to twenty hours of XDCAM HD material a week, you really have no excuse for not having a decent workflow. It's especially lame to stick with a known-to-be-suboptimal workflow and then rant about how Final Cut hasn't magically made your workflow awesome despite the inherent technical limitations. You're a very sharp guy, Chuck. You should know this.

what I know myself is that a tv facility, which I do some consulting for, is thinking about living Fcp for Avid or Edius.

it's tones of XdCam Hd daily and it's a render nighmare.

Their workflow is stupid, (that was before I got invited to the bal).

They ingest tones of programes and every second has to be processed and rendered. Hours daily. And they do that ingest (mostly with an upscale) as ... tadada ! XDCam HD ! Oui Monsieur !

because they have low network and lazy stockage bandwith. No enougt stockage to double it as DvcPro HD.

the worst: they actually film in DvcPro Hd and convert it to Gop in Fcp's timeline.

of course you won't find anything so stupid... the problem... it's real life. Formal consultant was a mor*n. So very bad investments have been made and they won't change a think because I say so. (The problem is that, therefore, the Omneon is configured for Gop also.

so you see Jeff it's not so simple.

They are actually telling me let's go Avid or Edius? At least those system will use all machines power... them !

is edius really multicore ? I need munitions !

I agree that rendering is not FCP's greatest strength.

Using the same 1920 x 1089 50i footage from an EX1 on FCP and Edius timelines, and using the same MacPro I get much better real time preview and rendering from Edius. Typical example: 29 minute program with only a 'Y Curve' filter applied (Natress filter in the case of FCP and Edius' own in the case of Edius) resulted in the following render times, FCP 2hours, Edius 15 minutes! Additionally, in Edius most filters will play back in full quality and at full frame rate without the need to render!

These are just a couple of reasons that Edius is making inroads into the broadcast environment.

So in my eyes Apple really needs to quickly address this problem. Don't get me wrong, there are many good tools in the the FC Suite that I use daily and Edius certainly lacks in the audio and alpha departments. If only FCP could match its real time performance......


Geoff

"It actually makes perfect sense. Computers are not magic. In order for Final Cut to run on a cluster, it would have to be written as a cluster application. It never has been. And for good reason; the amount of work necessary to abstract out the rendering module and replace the threading model Final Cut currently uses with a message-passing proc model would be huge, and it would provide no performance gains unless you were on a SAN. While there are a number of Final Cut sites out there that use Xsan or another SAN solution, there are vastly more that don't, so Apple would be investing thousands of man-hours in a feature that only a tiny percentage of customers would be able to use. "

That is ridiculous, I don't care if you have one system or fifty FCP systems, no one likes to wait these horrendous render times. If this was the case for all NLE's then I'd agree and say that's what it is, but that's not close to the case. In fact FCP's rendering is far slower than Premier Pro, Edius and Avid, to mention a few. So if they can figure it out then why can't Apple?

Also, unless FCP is written in Fortran, I'd hope its written in C++ then multi threading it should not take that long.

It might be ridiculous, Chuck, but it's also the truth.

I have to ask at this point: Just what exactly are you doing that gives you such fits? Are we still talking about the XDCAM thing? Because I addressed that above. XDCAM is a GOP format, and thus of course it takes longer to render. You can cut your render times in half minimum by tweaking your workflow pipeline.

As we've discussed, the issue is not multithreading. Final Cut Pro is already aggressively multithreaded. The issue that you first brought up was Qmaster, which has absolutely nothing to do with multithreading. In fact, Qmaster is the opposite of multithreading, because it's a message-passing multiprocessing model. It has to be to run on different systems over the network. It's what we used to call, back in the day, a federated distributed processing framework.

The other issue is one of workflow. XDCAM is not a computationally efficient format. Does Avid work with it more efficiently than Final Cut does? Maybe, I don't know. But rather than cursing the darkness, how about pulling out one of those matches Apple provided in Final Cut 6 and using ProRes instead? This is exactly what ProRes is for, y'know?

ok Jeff point taken

still ... sometimes (again) there are situations in real life where you MUST work with given format in a facility

real time and render are pathetic in Fcp. period
(and I am a Fcp lover)

now why not :
1 - admit it
2 - put some pressure on that last obstacle to happiness ?

"Why not admit it?" Because I simply have not had the experience you described. I guess I just don't see the virtue in trying to muscle through a suboptimal workflow, when making little changes to optimize that workflow is just so incredibly easy. Don't use heavy timeline formats. It's really that simple, at least to me.

yes but again

there are situations in real life where you MUST work with given format, idiots have decided.
you won't change it

do you suggest I should ask them to change all the investment they made ?
like ... the media port of the omneon which are Gop only ? they just won't

anyway... DvcPro HD or ProRes are not that fast either, compared with what I can see elsewhere. For my personal work I can take it (although...) but for daily broadcast jobs it's just a no way.

The problem I have is going from "We have made a conscious choice to do something that puts Final Cut Pro at a distinct disadvantage" to "Final Cut is pathetic." That's a non sequitur, and it doesn't work for me.

If you're in some situation, the details of which must be left to the imagination, wherein the only available option is to do something Final Cut doesn't do well, don't blame Final Cut. If you're having a hard time carving roast beef with a screwdriver, it doesn't mean your screwdriver needs to be sharpened. It means you're using a screwdriver to carve roast beef. Duh.

To be fair, I think the scenario thats being described here might be more analogous to carving roast beef with a bread knife ... not quite as bad as with a screwdriver, at least its a knife.

That's fair, but on further consideration I think an even better analogy is of trying to carve roast beef with the knife upside-down. It doesn't mean the knife sucks, it just means you're not using it right.

patronizing never seemed like a very professional attitude to me.

I am talking about a given situation, period

Is this thread going anywhere?

When life gives you dilemmas...make dilemmanade.

not any more