Andy Mees
Forum Replies Created
-
Hi Diego
Welcome to active forum duty 🙂
Make sure that you have placed your playhead in the sequence so that it is parked on the clip on which you are applying your color correction. Its actually surprisingly easy to miss that step, which means that you might be tweaking the settings but not actually looking (in the Canvas window) at the clip you are effecting. A good trick is to set the “Playhead Sync” mode to “Open” … in this mode you can be sure that what you see (and tweak) in the Viewer is going to be the same clip that you are seeing in the Canvas window.Hope it helps
Andy -
[Chris Kenny] ” But multiclips and, particularly, clips created by merging dual system audio and video, seem like they’d need somewhere to live other than within sequences. I mean, say you’re editing a feature film shot dual system. You might have thousands of merged clips. I don’t think you can just dump all of them in a sequence and work from there. You have to be able to work with them the same way you can work with standalone clips, prior to editing them into a sequence.”
Yeah, its possible in the GUI they might not be directly referenced as “sequence” data per se, but I’m suggesting that the internal data model of a sequence (ie AVComposition) would certainly seem to be able to be used to describe (and therefore to map) these otherwise ‘virtual’ clips. Whether or what discrete means FCP X might offer to create, manage and to present these “clips” we’ll have to wait and see … but certainly in the show and tell we heard specifically about built-in support for automatic handling and syncing of second system audio means “merged clips” are clearly designed in, plus we saw in the “oh look its out of sync” section that Randy “stepped in” to the clip item in the timeline to resync the attached audio track which suggests that the clip itself was either a nested sequence itself or was just being represented as one in the timeline to facilitate editing.
[Chris Kenny] “It has to be some sort of merged clip.”
That does seem to tick all the boxes.
[Chris Kenny] “probably like Color’s ability to import 3-way correction done in FCP: a starting point”
Yep, I think we should be able to reasonably hope for this.
-
[Chris Kenny] “…there is no unique challenge here. FCP X won’t really be doing anything when reading/writing those files that isn’t conceptually equivalent to what FCP 7 already has to do. And the things represented in those files — clips, tracks, sequences — map very well onto the data structures AV Foundation offers.”
Agree absolutely. The import of an FCP Classic project will mean interpreting and writing that data into a new internal data format, in the case of FCP X that may mean populating an FCP X database document … a much more complex operation than any normal FCP update requires certainly, and not all project data may be mappable, but as you say not conceptually different from what already happens.
[Chris Kenny] “I do see two potential issues for file conversion here.
One is that as per my speculation here, FCP X might not even have project files. That’s fine for sequences — it can just ask you what sequence you want to import, and then save it out as an FCP X sequence file. And it’s fine for regular clips. They just like in your footage library. But what about ‘virtual’ clips — subclips, multiclips, etc. that don’t exist as discrete entities on disk? How do those get imported? For that matter, how do they exist at all in FCP X outside of the context of a sequence, if it really doesn’t have project files anymore?”
Regarding ‘virtual’ clips of any description and how mapping those might be handled … actually I’m thinking FCP X should excel here. Apple appear to have really embraced the power of metadata in this rewrite, and as such it would seem that any virtual clip (which inherently exists physically only as metadata) should be quite easily mapped to new metadata sets. “Sublips” (as in FCP 7 for instance) seem to have been replaced in FCP X by “Ranges” … a simple range based keyword would certainly seem capable of describing what was previously the virtual representation of a subclip, so I could see them being mapped as such. Multiclips … thats harder to make a guess at exactly how it might be mapped as we’ve not seen if or how FCP X 1.0 will handle that functionality … but personally I’ve found FCP 7’s current multiclip implementation to be somewhat fragile ( especially when compared to the multiclip handling offered by other platforms ) and I would hope to see it largely rewritten perhaps dropping the “virtual clip” aspect altogether. That said, perhaps an existing FCP 7 multclip might be mapped as a unique FCP X sequence itself, the collapsed multiclp in the master sequence as a clip collection (nest) … then again, Apple being Apple, they’re probably wrapping the whole thing up as something far more complex and clever, so get ready for “Dynamic Auditioning” (you heard it here first folks, lol).
[Chris Kenny] The second is that, of course, some filters present in FCP 7 might not be present in FCP X, or may render a little bit differently. Or take, for instance, the color corrector — it seems to have been totally changed in FCP X. Will corrections from the old FCP come in at all? I suspect you won’t, on complex projects, quite be able to export an ProRes file from FCP 7, then open that project in FCP X and export a second ProRes file that looks frame-for-frame identical. But these kinds of issues across versions are not all that uncommon (page layout software can even reflow text, etc. after upgrades), so while I’m sure there will be a lot of griping at the cleanup required, history suggests this sort of thing is not the end of the world.
“Yeah, I think we can hope for effects to map if and where they’re specifically present in both versions of course, but where not (or where significantly changed) then I think folks will have to live with some degree of manual cleanup (and that seems fair enough). Going into slightly unhinged speculation mode, whilst it seems unlikely, we may yet discover that some of the really pervasive “Effects” from FCP Classic (like the 3 Way Color Corrector, that would appear to have been wholesale replaced in FCP X with the Color Board ) may yet also have been ported as “Effects” in FCP X, strictly to provide such compatibility (and familiarity). Ok yes, padded cell moment perhaps.
As ever, time will tell.
Andy -
Very fair point Simon.
-
Probably only fair to point out that in the demo they don’t state directly that it was the “same project”, only that the two screenshots contrast and compare how an edit (with every single frame and every single cut in the same place) looks in each version … and yes, given that then it certainly “could” have been rebuilt specifically for demo comparison purpose for the demo. I’m still inclined to think tho that just plain common sense (if not direct evidence) points to XML interchange compatibility.
-
Well remembered Mr Shields, yup theres certainly plenty to suggest that project compatibility will be covered.
-
I get you … yeah, the depth of the shot analysis / automated metadata tagging was surprising … and by extension that does lend itself directly for use with the “Smart” collections. Good stuff.
-
>Nobody has anything constructive to add
Did you get out of bed the wrong side this morning Chris? This is the FCP X forum, of course there is rampant speculation in here, how could there not be?
You’ve got a brain up there, why not consider the question and put forward what you think might be valid arguments for or against the supposition? Simply harping on with the same canned response is getting a bit old. -
>Seriously, the “What’s the worst thing that could possibly be true about FCP X?” game is getting really, really old.
So stop playing Chris, you don’t have to comment on every thread, especially if you have nothing especially constructive to add to it.
-
We know that iMovie can export projects in FCP 7 XML format which suggests that some form of translation between FCP X and FCP 7 (and hence visa versa) is not necessarily unknown territory. Universal compatibility, function for function? That would seem doubtful, but I’d expect it to be largely compatible. Much as one might simplify aspects of FCP 7 project before sending out to Color, I could see more complex FCP 7 projects needing some simplification before exporting as an XML that would be compatible for import to FCP X.