[Mathieu Ghekiere]

Hi Bill,

I started using X after 10.0.3, and had a consistent hate-love relationship with it.
I always discover things I really like, and I also discover features that I wish are there and that make some things harder.
I used it on about 10 paying projects until now, and nobody wishes to use it more at work than I do because of some features it has that FCP7 doesn’t have. But I have to be neutral too, if FCP 7 works faster in some workflows, I will have to keep on using that on some projects.

Apple has been pretty good at listening to people’s wish lists, and adding features. I still have a list with some to me, really key-features. I’m not questioning FCP X’s ability to edit. It’s much easier to edit something with lots of interviews and B-roll in X then it is in 7. But the more special editing of medical videos, the way we record them, etc., I first have to do some tests to tell if X is a good choice for that.

[Mathieu Ghekiere]

Hi Bill,

I do know how FCP X works, and I know about keywording etc. It’s one of the reasons I’m using it for a project right now which has many many clips.

And I admitted in my first post that I still have to do some testing in how to possibly edit operations in FCP X using another workflow, it’s on my to-do list. So you are right that I have some testing to do to see how we can edit such operations in X, but X doesn’t (seem) to make it as easy as in 7.
Again, I reserve final judgement, but whatever conclusion I come up with, you are not going to persuade me in the fact that Timecode isn’t important anymore, and that the timecode HUD in FCP X doesn’t lack.

But that doesn’t mean I thought about it a lot.

For instance:
now we often record on a Nanoflash, which splits its recording over clips that are no longer then 13 minutes (depending on the codec). The cameraman who runs around in the OR runs around with a timecode locked camera, and does not record it all in one take (depending on the operation).
Sometimes a Nanoflash seems to miss a couple of frames, if I put them on the timeline, sync with the other sources in FCP 7. It happens, but we can very quickly re-adjust based on the timecode overlay in the canvas. Where I see ALL the timecodes of everything on my timeline at once. And if they are the same, they are all green, if not, one is purple, seeing it very quickly visually if something is off.
If I don’t, it could be that a clip that contains no audio, is of a patient monitor of a close-up of a device a doctor in holding, doesn’t match with the first layer of the complete recording with audio. But I wouldn’t never know, because doctors were masks, so you can’t see their mouth, and there are also monitors which we don’t understand the information from anyway.
In FCP X, the timecode HUD is only of your sequence, unless you also use clip skimming, but it really is much more difficult to compare timecodes going trough each layer, especially with skimming which can be very sensitive, in comparison with just seeing an overlay with ALL the timecode layers on that moment in time.
The magnetic timeline doesn’t help too. If I finally put them above each other, and I cut something away, and it moves, it can mess up sync, and I would not know because not everything contains audio and there are no visual cues for me, except for skimming trough every clip on the timeline again.
Yes, there are ways to get around the magnetic timeline (shift+delete, the position tool), but it’s more easy in this case to do make errors. If you made an error in FCP7, I would immediately see it in the timecode overlay.

Multicam wise, there you can pick your angle. But doctors often want to see multiple angles at once. So then you would have to put multiple multicam clips above each other. Now, I know you can also synchronize multiple video angles in X, placing them above each other, but I haven’t tried it out yet, and it’s definately on my to do list. I really will have to see how it works, so I’m gonna reserve some judgement there.
I’m afraid that you very quickly loose sight of the ORIGINAL timecode of your source clips, and in our case, that’s very dangerous because we as non-doctors are often not equiped to notice that immediately.

Your advice about the keywording, I will definately take in if I do that testing in FCP X, but don’t forget that as the Nanoflash spits its recording out in many files, and the cameraman record in many smaller clips, it would require a lot of work-arounds in keytaggin, multiple keyword collections, etc.
And only because FCP X doesn’t contain a better timecode HUD which FCP 7 had with its timecode overlays. If one operation takes me one click in FCP X, and 5 in FCP7, using new methods, I’m not afraid to defend FCP X. But if the opposite is truth, we should be critical of FCP X, and hope that it gets better in future releases and not say that ‘oh well, timecode is irrelevant anyway’.

BTW: we are looking into new recording options too, that will record on longer SSD’s in one take, and get audio and timecode from every source together. A lot of what probably makes editing an operation in FCPX more difficult, will vanish then, but again, the lack of not having a source timecode reader filter (or generator), and not having timecode overlays that immediately show you which timecode everything on the timeline has now, makes for possible work-arounds and lots more of keywording, tagging, ranges selecting up frond. Which is that it will take a lot more time for certain operations then now in FCP 7 where we can just drop these clips in folders, and place them quickly on a timeline, put a timecode READER or generator filter on it, and be done with it. I can do this for a 4-hour case in 10 minutes, beginning to end if there are no complications. Even with your methods of tagging, keyword-collections, etc; it will take me a lot more time.
The reason why we are looking into it, is because FCP X is in many ways a better tool in using the hardware, and some very nice features that I already miss not having in FCP 7.

[Mathieu Ghekiere]

Sorry Bill, but I have to disagree there.
The function indeed needs work, and you can’t just give your example of why it is necessary.

I’ll give you another one…

We often record medical videos. If an operation happens, we record from multiple feeds.
The sources are often medical monitors, with things like an echo of a heart, heart meassure monitors (EKG), endoscopic views, and a boom view of the operation table.

We don’t record Audio in every single source. We timecode all these recordings. Recordings are often multiple hours long.

If I’m together with a client (a doctor), and we edit the video, and we are going trough a frame and he wants to see what happens on another medical monitor or something, for me it’s very quick to find. Look at the source timecode, type it in and get immediately to that timecode in another video which I don’t visually understand (I’m not a doctor, I just see 4 hours of black and white material that I don’t understand, but they do!). So yes, Timecode IS important!

That’s only one example. If we need to sync all these sources in a timeline, so 6 sources in a 4 hour timeline, we can do it very quickly now with the timecode viewer overlay in FCP 7. I don’t even have to have audio in every source, I can just visually see it and objectively see it.
Afterwards you put a timecode reader on ONE of the sources in a split screen, if you want to export a copy for the client to see. Yes, I want that timecode reader to be on the SOURCE timecode, so if the client makes comments with timecode notes, I can quickly go and see in the SOURCE material where it is, and I’m not locked in a sequence/timeline (especially not one that is magnetic).

We had a source timecode reader before 10.0.3, and because Apple changes something in the way Motion behaved with Timecode Generators, it doesn’t work anymore, and it’s a pitty. That, and having a timecode HUD again is one of my most requested features of FCP X.

And btw, a multicam sequence isn’t always helpful for us, because we often need to edit with picture-in-pictures. So, although I’m checking in how far I can use FCP X for this with new methods of working (Synchronizing clips based on the same timecode, haven’t tried it before, except for synching audio and video) , it’s still some work-around for what could be better.

[Mathieu Ghekiere]

Difficult Question…

1. The reason why your exports are taking so long, I think are because of 2 things:
– the Timecode Filter. It takes ages to render. It’s just fact.
– You’re talking about rendering a low resolution video. FCP6 and 7 only use like 2 cores or something, so it’s better to export a full resolution movie with timecode, and then rendering a low resolution from that in Compressor. That way you are not giving old 32-bit FCP 7 a hard time rendering 2 things at once (compressing + timecode filter) and you can use a Cluster in Compressor to make a lower resolution video faster.

2. Will X render faster… X renders effects faster, often, yes. And with the last 10.0.6 update it also can export in the background, so you can work further. I would still recommend doing the same there, first exporting a full resolution Master File, and exporting a lower resolution later from Compressor.
BUT, kicker… In X you only have a Timecode READER filter, not a timecode GENERATOR filter. Maybe that isn’t a problem to you, I just let you know.
Other, more serious problem… The timecode filter only gives you the timecode of your sequence in FCP X, and not the timecode of your source clip… Can be a big hurdle. It used to work with a (free) 3rd Party Timecode Reader filter by LeoHans, but since the 10.0.3 update it stopped working.
I think Alex4D has a big work-around on his website now, but it’s that: a big work-around.

[Mathieu Ghekiere]

As other ones said, I work with XDCAM material in the same way in FCP X as I did in FCP 7: going trough XDCAM Transfer which doesn’t transcode and only rewraps.
We had been doing this in FCP 7 for 3 years now at our company.

There is a ‘gotcha’ though…

In FCP 7, which was based on the Quicktime Framework, you had access to Smart Rendering.
If you were in an XDCAM timeline, only cutting simple XDCAM material, without effects or so, FCP 7 just copied the original media when exporting. You can do a very fast export when you just use ‘Use Current Settings’.

The problem is, if you try the same with FCP X, in Current Settings it exports to Prores. So it converts everything on export. It does this pretty quickly, even on lowly hardware, but not as fast as the export in FCP 7.
Yes, you can now export to XDCAM codec in 10.0.6 (you could do that before too), but it still re-compresses. Then it takes even longer than when you export to Prores in my speed tests.
Test it. You’ll see. I’ve also noticed performance of those Quicktime wrapped XDCAM material to be slightly worse in FCP X then in FCP 7 on the same hardware (written about that here: https://forums.creativecow.net/thread/344/13326) but I didn’t retest this in 10.0.6

I’ve written about the lack of smart rendering in FCP X in this thread:
https://forums.creativecow.net/readpost/335/35862

If you work with Prores, FCP X gets the same speed as FCP 7 or faster.

We work like you, on congresses, with very quick delivery, and because the lack of smart rendering we won’t be able to use FCP X. We can use it for other assignments though, although some things also depend on having a more detailed timecode-HUD and timecode reader/generators (that work on source clips). But that’s off topic.

Another thing:
since 10.0.6, Apple announced support for native MXF media, which lots of XDCAM cameras record to. You do need a 3rd Party plugin, that costs money.
If someone has one of those, could they tell me if FCP X exports more quickly with XDCAM material? As fast as the speed that FCP 7 did? (which was pretty much the same speed as copying the media in the Finder)

[Mathieu Ghekiere]

Reference movies would be nice, but what I would like even more is getting Smart Rendering back.
In FCP 7, when you imported media in a timeline, it became that media-timeline.
If you put in XDCAM in a timeline, it became (if you say so) an XDCAM media-timeline.
If you just put some media in there, cut few simple things with dissolves, without any effects, and all the same codec, FCP 7 would just export very fast by copying the original media and just adding the fades.

FCP X recompresses everything. Only when you work in Prores, it seems that export is as fast as copying in FCP7. I did lots of tests, even with 10.0.6.
Yes, rendering from XDCAM to Prores is fast in FCP X, but it’s still 5x as slow as the fast copying FCP 7 did.

For the work on congresses where we have tight deadlines and lots of media, this kills FCP X for us. We can use it for other projects, but untill Apple has that covered (or has export times as fast as FCP 7 in these scenarios, but a 500 procent increases seems unlikely for the moment), we will have to keep using FCP 7.

Reference movies would be great too, but the above is a bit more urgent for me, because with reference movies you of course always have to have the original media connected.
I sent Apple feedback a couple of times about this, so I hope they are thinking about it.

[Mathieu Ghekiere]

Yes, starting from 10.0.1 (I think), FCP X started using it’s GPU too for the exports.
So I would guess the trial to do the same.

I think FCP X is pretty okay in exporting a Master Prores File in comparison with Compressor 4, I think maybe even faster…

Well, I think you know that editing H.264 isn’t the best codec to work with. And that what you are essentially doing is moving all the transcoding work to the end of the job, at the export, instead of doing it in the beginning. This can be the best for your particular workflow, I’m not going to decide.

Still, maybe there are ways to speed it up, though. FCP X rendered out a 1 minute XDCAM clip to Prores in about real-time. (1 minute), on a 13″ Macbook Pro. XDCAM works better than H.264 though, but you are getting more then 10x real time exports.
I don’t know where your problem is though, did you do a lot of effects? Or just exporting a cut-cut?

[Mathieu Ghekiere]

FCP X renders very quick to Prores. I notice this with XDCAM, H.264, other flavors of Prores, …
If you are rendering immediately to H.264 I think you are doing a very difficult compression job for the computer, going from H.254 to another H.264.

The problem is that FCP X recompresses anyhow. It doesn’t have a smart render, like FCP 7 had, where if you just did a cut-cut edit (like on XDCAM), it would just copy the original media for the export, resulting in very fast exports in FCP7 (if no effects were applied of course).
I’ve asked Apple a couple of times to add this in, because we really would need it for some fast-deadline work we do on congresses.

I would suggest you to just export to Prores 422… See how long that takes. If that takes a LOT shorter, then afterwards take that Prores file, and compress it trough FCP X or Compressor 4 to a new H.264.
I would not be very surprised IF you would get a shorter complete export time going first to Prores and from Prores to H.264 than from H.264 to H.264.
Good luck! Let us know how it goes!

[Mathieu Ghekiere]

I’ve noticed the same thing: Importing for instance 100 XDCAM clips into FCP 7 just goes IMMEDIATELY. If you blink your eye, the importing dialogue box is gone.
In FCP X, it takes its time.

But as others said, it’s doing a bit more then FCP 7 too, and I still am in love how in the audiowaveforms of FCP X you can immediately see where audio peaks. Still.

I hope, next to (hopefully) many requested new features in 10.0.6 (leaked in a Red Giant Movie tutorial video today), that there is still some optimizing of the software being done.

[Mathieu Ghekiere]

Many people use X2Pro to send their mix, with roles (and since version 2.0 also Audio Handles etc.) to Pro Tools. I don’t need it at the moment, but the software has gotten very good reviews:
https://www.x2pro.net