[Johnw3d]

If you do wind up doing a lot of boring old pans & zooms, you might find the plugin I developed for a recent long-form historical doco useful. It helps getting pixel velocities uniform and does synchronized eases on zooms & pans, which is a pain in FCP. Unfortunately, it won’t do the 3D parallax layering for you, though that does sound cool. It’s called Pan Zoom Pro, you can get a demo to play with here: https://www.lyric.com/fcp-plugins/index.htm#pzp.

Cheers,
John

[Johnw3d]

I usually capture the advanced-pulldown footage directly as 30i DV then apply the Advanced Pulldown removal Tool to the footage after it’s in, at which point it becomes 24p. My understanding is the tool will only work on advanced-pulldown footage, and you can’t over-apply it.

[Johnw3d]

Wow, that’s terrible! Of all the things a bug in video program should *not* do is trash your source video files. Geez, that’s about the biggest, number 1 stop-ship bug I could think of. Have you enquired over in the Shake forum here?

I’ve just acquired Shake and I’m about to do some playing, but maybe I should be careful not to point it at any important video. Did this happen just on a send-to, or did you also do some work in Shake on the sent sequence?

I really feel for you, wish I could offer some help.

[Johnw3d]

Yes Chris, it should work just fine in 5.1, Intel or PowerPC. Apple doesn’t change FXScript often and certainly not so much as to break all their existing FXScript filters, transitions & generators, which means 3rd-party FXScript plugins are carried along for the ride.

Cheers,
John.

[Johnw3d]

Basically, any plugin that is built in FXScript should run in 5.1 without change; FXScript is processor-independent. So, Natress, GFilm, Eureka!, Telly’s and others like Joes Filters & my Lyric Media plugins should work unchanged. Any plugins written in C or C++, such as those that use the AfterEffects plugin loader in FCP, may not work particularly on an Intel Mac.

[Johnw3d]

Has anyone downloaded the v1.33 demo and tried it with FCP 5? We think its ready to go live, but it would be great to get any feedback before we release it.

Thanks,
John.

[Johnw3d]

Generally when the XML imorter complains like this, you’ll still get a reasonable sequence, with the problematic clips left out. If you open the XML in a text editor and look at the lines mentioned, you should be able to deduce which are the problematic clips, by looking at the closest <clipitem> element and at the <name> element inside it. Also, there’s a <start> element which gives the clip offset in the sequence in frames, which might help you locate the troublesome spot in the timeline.

Hope this helps,
John.

[Johnw3d]

Thanks for all the kind words everyone, I’m glad you are finding it useful.

Regarding, FCP-5, I now have a candidate update which is undergoing testing. There’s a demo version available here, https://www.lyric.com/downloads/LyricPanZoomProDemo1.33.dmg.bin, in case anyone wants to try it out. Feedback most welcome. Note that this version has an extra slider in the Display section at the bottom of the PanZoomPro control panel. This lets you adjust the size & thickness of the framing rectangles and label graphics, since FCP-5 has removed the ability for plugins to scale their on-screen graphics based on current Canvas resolution and zoom-level.

All the best,
John
Lyric Media

[Johnw3d]

Tom Wolsky posted a suggested reason for the clip-splitting on the Apple board. Starting & stopping recording on an HDV camera interrupts the GOP structure, since you might stop recording at any frame, usually not an I-frame. The thought is that FCP5’s native HDV editing requires consistent GOP structure within a clip, and so must split clips where the structure is interrupted. This is a good explanation, but it would be disappointing if true, since FCP5 already has to handle broken GOP structures as it plays through non-I-frame cuts and over clips that don’t end on a GOP boundary, so it seems reasonable it should be able to handle it within a clip.

I think this is going to annoy a lot of people who are used to load-the-whole-tape-and-slice-and-dice logging, until they get used to plying through all the clips a capture will now generate.

John.

[Johnw3d]

Same here with a Z1U, what a pain. So, I tried DVSHCap on the same tape and it came in smooth as silk, and reported *no* time code breaks. Are we sure it’s a TC break problem and not just a really, really helpful feature in FCP5?

John.