[ This article was first published in the September, 2009, issue of
Larry’s Final Cut Pro Newsletter. Click here to subscribe. ]
Lachlan Coles sent this in:
I’ve observed many different ways of setting up Capture Scratch, and having worked in a busy production environment where many different editors used the same machines, I came up with a system that works well and could be worth consideration by others.
I settled on this system after wondering where all our drive space had gone and then finding files within a Capture Scratch which was within a Capture Scratch which was within another Capture Scratch within etc. (I’ve skipped about 5 nested Capture Scratches for brevity) – all of the afore-mentioned Capture Scratch folders containing media captured by different editors, relating to different projects with no easy way of determining what media was for what project.
Aside: many of the clips in those days were “Untitled1” etc.
On any drive I use these days, I create a Projects folder for my project files (usually prefixed with an * so it appears first in an alphabetical directory listing on the drive), and then I set Final Cut Pro’s Scratch Disk settings to the root level of the drive.
For example, if the drive is named “Projects July 2009”, under System Settings… in FCP, I click Set… for Scratch Disks, and then select “Projects July 2009” – likewise I do the same for Waveform Cache and Thumbnail Cache.
This creates Audio Render Files, Capture Scratch, Render Files, Thumbnail Cache Files and Waveform Cache Files folders on that drive at the root level. (I set Autosave vault to a different drive than the current project drive as I prefer not to lose my Auto-Saved project file copies if a drive fails …)
The main advantage of this system is that each new project I create and capture footage in, gets its own folder within the one Capture Scratch folder – so I have no need to create a folder for each project and nest a Capture scratch within it, leading to numerous nested Capture Scratches and media going everywhere when other editors forget (no!) to set the Scratch Disk to the appropriate folder.
I’ve provided screenshots to give a clearer idea of how this works.
The system makes it easy to keep all files organized as there is only one place for them to go – the Capture Scratch folder of the project’s name. All media relating to the project, whether captured or not – such as stills or audio files – are added to the project’s Capture Scratch folder. It’s that simple.
A massive sign urging editors to check their Scratch Disk settings before commencing their session does not go astray – and naming clips when capturing them always helps too. ;o)
AND NOW MY TWO GRIPES
Lachlan continues:
Keyframing
Keyframing in the Motion tab in Final Cut Studio 3 is still as crusty as it was many, many moons ago. I’m talking about when you click on a keyframe to drag it to a new location within the motion tab, i.e. for scale or position, and the field you are adjusting slips in position. In the screenshot below, I’m dragging the Center keyframe to the start of the clip after having extended the clip in the Timeline and double-clicked it into the Viewer.
It’s annoying and I’m stunned that it is still a “feature” of the new release. (Maybe it has been left like this to encourage us to use Motion for all keyframing …)
Reconnecting Offline Media
FCS 3 still doesn’t seem to be able to tell the difference between file types when reconnecting offline media.
i.e. if you have a picture called Riding Group.png and another called Riding Group.psd, FCP will decide that the .png file is the .psd file and present the .png file for reconnection, EVEN when it is supposedly looking for the .psd file.
It gets worse.
Recently I needed to transfer a project I received from an external drive with a bunch of scans in four separate folders. The scans were titled scan0001.jpg, scan0002.jpg etc. (not my preferred naming convention I must admit …)
All four folders had a scan0001.jpg, scan0002.jpg and so on … After duplicating the media and the project file, Final Cut decided that scan0005.jpg in the folder Marisa was actually scan0005.jpg in the folder Grazia. If I had not been concentrating, all files in this path would have replaced the original files in the timeline.
i.e. when reconnecting a file that is now on a different disk, FCP presents files in a completely different directory path, even when it appears to know the correct directory path. In the example below, the project which was on Transfer Disk is now on Projects July 2009. Even though the file structure of the two disks is identical, Final Cut cannot find the correct media by itself.
I guess this is a compelling argument for giving all files individual and distinctive names and perhaps for using the Media Manager when moving projects around, though I do find there are situations where the Media Manager is not appropriate.
For a PRO level application it’s a little disappointing that Final Cut is still so easily flummoxed.
Perhaps the Studio bundle needs a Leopard to Snow Leopard style makeover where existing code is refined and made to work properly. I’m sure if you asked any editor, they’d have a list of pet peeves and gripes that they consider long overdue for fixing. Perhaps we can BUG Apple to fix outstanding issues in the next release – surely a full 64 bit Cocoa version of the Application(?!)
Larry adds: Lachlan, thanks for sending these in.
[ Go to Top. ]
John Magin, of Pro Video Services writes:
* The biggest issue people have is Project file sizes. I can’t tell you how many calls I’ve made at sites where people have brontosaurus sized project files and then wonder why they won’t open, or take forever. My rule of thumb(nails) is under 100 MB. A lot of times these people (often indie feature and documentarians) are on a budget and their systems aren’t up to handling the load. Add to that any renders they might want to do and it will spike the RAM/CPU activity. 4 GB these days is bare minimum. I’m building out systems with 10 to 32 GB of ram.
* Also, as far as the FCP prefs go, I’ve never had an issue with trashing the whole User Data folder w/ caveat of losing setup/window prefs- as FCP auto-generates the whole shebang.
* I’m also a strong advocate of Anders Holk’s FCP Rescue and Applejack – but don’t run Applejack on SAN mounted volumes( or disconnect) as it can screw with umask/permissions on the LUNS.
* And as far as capture drivers go- always go to the website. The disks they provide are usually 6 months out of date as they’ve been sitting in the box for who knows how long. I really wish AJA would just save on plastic and print a link to their website. Same for BlackMagic.
Larry replies: John, thanks for writing.
I agree completely that if project files get bigger than 100 MB, trouble is just around the corner.
I disagree on the need for more RAM. FCP 7 and earlier can NOT access more than 4 GB of RAM. This will change with Snow Leopard AND an upgrade to Final Cut. More RAM helps when running multiple applications simultaneously, but not FCP itself.
The problem with trashing the entire User Data folder is that you run the risk of losing custom keyboard, button, timeline, browser, and window settings. Since I have never known these to corrupt, trashing the entire folder seems a bit draconian.
I am a fan of Anders Holck’s FCP Rescue, EditGroove Software’s Usermatic, and Peake Professional Systems Final Cut Assistant
I also agree that downloading drivers from a website is always a better idea than from a DVD.
