[Joseph Owens]

The old config guide states Slots 1 and 2 for the 120-UI / 285-process GPU. Beyond that, driver creep has been noted among the various OS updates and card versions… so possibly more likely to be the issue. I guess the old “re-seat”-the-cards diagnostic might be worth a try.
After all 90% of all electronic faults are connector-related, and the other 90% is power supply.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Mark Suszko] “Low price is the best anti-piracy protection: by reducing their profit margin, you make the reward for high-volume piracy worth less than the hassle.”

Harks back to the days of AutoDesk AutoCAD, when its license per seat was deemed outrageous. Of course piracy was rampant.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

Yes, its essentially a Copy/Paste operation.

Right-click and “Copy” the clip that has your master motion tab settings.
Right click on the clip that you want to transfer these settings to… and select “Paste Attributes”. You will get a submenu from which you can select the appropriate items, including Basic Motion and a few other things.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Jason Watkins] “Is there a way to get FCP to burn-in true 24 frame timecode over a 23.98 clip or sequence?”

You might have to try to create a new timeline and deliberately set its frame rate to 24.000, then re-nest the 23.98 fps sequence into it. Don’t let FCP try to override. Bon chance.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

If you take a quick peak down the list, I’ve stated my reasons (and FCP’s preference) for working in native framerates. Its in the 29.97/23.98 pulldown removal thread.

So 23.98 would be better. Unfortunately, the 29.97 stuff won’t look particularly pristine, and the conversion to 29.97 at the end of project for the entire timeline is fraught with danger, especially if this is going to tape for deliverable (assumed). FCP does only 2:2:2:4 to tape from a 23.98 timeline (unless you do a deliberate Compressor 2:3 Upper-Field conversion), and 2:2:2:4 is unacceptable for broadcast (although you see a lot of it that has somehow gotten past QA).

If you are closed captioning at the same time, the Edit-to-Tape module can only do that insertion if you are operating from a 29.97 timeline, anyway.

Things are a bit of a mess at the moment with on-line mastering.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

I also posted this to the original thread, and this is the exhaustive answer.

“Pulldown” is introduced into field cadence when making the transition from 23.98P to 29.97 interlaced. FCP doesn’t actually do the pulldown removal correctly because the cadence has been destroyed by the editing process. Been through this a million times, as I used to run a telecine film-to-tape and tape-to-tape operation. Yet it remains very poorly understood.

Four “film or progressive video” 23.98 frames become ten 29.97 interlaced video fields. There are several ways to accomplish this: SMPTE standard is 3:2:3:2 (B-Frame dominant), while what is in general practice is A-Frame dominant (2:3:2:3). There is Advanced Pulldown, which is 2:3:3:2 (which is rather clever for a number of reasons), and then there is what Final Cut does, which is 2:2:2:4, which is unacceptable for anything but previews, but that’s all it can do, because nearly all NLE’s are not field-aware. However, your HDV source material is 2:3:2:3, complicated by the fact that it is IBP-Long GOP. That it has been edited that way has introduced some serious, probably fatal impediments for ever going back to 23.98P.

If you don’t recognize the ABCD notation:
The first 23.98 frame is mapped to the first two video fields (one ‘whole video frame’) and that is an “A” Frame. Example: If film is shot at 29.97 and transferred to video at 29.97, then every frame is an “A” frame.
The next 23.98 frame, the “B” Frame is actually mapped to three video fields, in fact one-and-a-half whole video frames, and straddles video frames 2 and 3. A “C” frame is mapped to the next 2 fields, but straddles two video frames — the second field of Frame “3” and the first frame of Frame “4”. The last 23.98 frame in the sequence, the other 3-field case, the “D” frame, straddles field 2 of Frame “4” (Video) and both fields of Frame 5. and then it repeats.
If you edit 29.97 material that has 2:3 interlaced-field cadence, then every time you make a cut on any random frame (and you can only cut on frames, not fields) you have an 80% chance of disrupting the ABCD field order. That is why some of your clips look great, and some of them look stuttery — mostly bad as the odds are considerably less than 50/50 of getting it right. If you apply the same “reverse telecine” dominance to all the clips, then you will more often than not get converted footage that is “out of step”, since it is looking for ABCD and getting something else, like CDAB, and that ain’t going to be pretty.

Its also why there are black holes in timelines when you simply plunk 23.98 edit sequences into a 29.97 timeline. FCP, for sure, simply can’t do the math with 2:2:2:4, and as I have stated, that is the only practical mode in which it can operate — even though the cadence options exist as selections — they are simply there for cosmetics, because they don’t actually work or affect anything.

It would be nice if FCP-X fixed this, but I get the feeling that the APPLE architect doesn’t understand this concept, either. If it was simply a weakness of Quicktime, that would be great and maybe there is still hope.

If you used SHAKE to remove the ABCD fields, then you would realize that you have to reset the removal dominance to whatever is appropriate for that specific clip. Editing, statistically, is a random reordering process, and that is what you’ve got — random 2-3 field cadence. You are correct that a re-edit, at 23.98, with material from which the pulldown has already been removed, is probably the only thing that will fix this. The Final Cut manual specifically states that you should remove the 3:2 pulldown from this kind of material prior to doing any editing, so that you are dealing with the native framerate of the source material, and editing “whole frames” instead of disrupting the pulldown.

Just as a footnote, the use of the term “pulldown” to describe the repeated-field cadence strategy is not precisely correct. More accurately, the term describes the mechanics of “pulling down” the frame rate of film which was originally shot at 24.000 fps to 23.97659 fps to more correctly match the video field speed of 59.94 fields per second. “Pulldown” started being used as a shorthand term which covered the entirety of that conversion. Like “fonting” a lower-third is not really good technical language either.

But, hey, its all about process, right?

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Elijah Lynn] “it appears that FCP removes the pulldown, the other section looks very stuttery like there is a framerate mismatch, it is the same source file for the length of the sequence, they both have the same clip attributes and all numbers in the motion tab are whole numbers. I am lost as to why one section looks great and one section looks horrible, this issue could end right here if I knew the answer to this question (& could solve it).”

“Pulldown” is introduced into field cadence when making the transition from 23.98P to 29.97 interlaced. FCP doesn’t actually do the pulldown correctly because the cadence has been destroyed by the editing process. Been through this a million times, as I used to run a telecine operation.

Four “film” frames become ten video fields. There are several ways to accomplish this: SMPTE standard is 3:2:3:2 (B-Frame dominant), while what is in general practice is A-Frame dominant (2:3:2:3). There is Advanced Pulldown, which is 2:3:3:2 (which is rather clever for a number of reasons), and then there is what Final Cut does, which is 2:2:2:4, which is unacceptable for anything but previews, but that’s all it can do, because nearly all NLE’s are not field-aware. However, your HDV source material is 2:3:2:3, complicated by the fact that it is IBP-Long GOP. That it has been edited that way has introduced some serious errors for ever going back to 23.98P.

If you don’t recognize the ABCD notation:
The first 23.98 frame is mapped to the first two video fields (one ‘whole video frame’) and that is an “A” Frame. If film is shot at 29.97 and transferred to video at 29.97, then every frame is an “A” frame.
The next 23.98 frame, the “B” Frame is actually mapped to three video fields, in fact one-and-a-half whole video frames, and straddles video frames 2 and 3. A “C” frame is mapped to the next 2 fields, and straddles two video frames — the second field of Frame “3” and the first frame of Frame “4”. The last 23.98 frame in the sequence, the “D” frame, straddles field 2 of Frame “4” (Video) and both fields of Frame 5.
If you edit 29.97 material that has 2:3 field cadence, then every time you make a cut, you have an 80% chance of disrupting the ABCD field order. That is why some of your clips look great, and some of them look stuttery. If you apply the same “reverse telecine” dominance to all the clips, then you will get converted footage that has the wrong cadence progression.

If you used SHAKE to remove the ABCD fields, then you would realize that you have to reset the removal dominance to whatever is appropriate for that specific clip. Editing, statistically, is a random reordering process, and that is what you’ve got — random field cadence. You are correct that a re-edit, at 23.98, with material from which the pulldown has already been removed, is probably the only thing that will fix this. The Final Cut manual specifically states that you should remove the 3:2 pulldown from this kind of material prior to doing any editing, so that you are dealing with the native framerate of the source material, and editing “whole frames” instead of disrupting the pulldown.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Alex Udell] ” without having to re-download the software each time?”

Probably would simply need a new key.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Jeremy Garchow] “Resolve… that will surely change.”

My read on this is that R8 (because it supports multi-layer sequences, would have to do things that way.

Its just a markup language for pete’s sake.

jPo

You mean “Old Ben”? Ben Kenobi?

[Joseph Owens]

[Joseph Mastantuono] “I imagine that at a certain point the faster more capable ati cards we have available on mac will outclass our gtx285’s, even if they’re not CUDA enabled.”

I would doubt that, especially since OpenCL is based on CPU-processing and has nothing to do with the GPU, other than it flags processing to the cores. But if you are then missing an entire component like Noise Reduction (CUDA-only as I read it), I would hesitate to class that as “more capable”.

Other than making the application available as a limited function on less-than-fully-fledged platforms, it doesn’t look like OPenCL enables much more than a highly-leveraged simple solution and cannot take advantage of multi-GPU installations. So to take advantage of its full capability, Resolve8 still appears to be very much a CUDA/nVidia app for the foreseeable future — but at least we can see further ahead with this than we can with some other applications which were “sneaked” to a still-bewildered and spinning-out-of-control public.

jPo

You mean “Old Ben”? Ben Kenobi?