Originally Posted by Haggar
Considering that FCP X can import iMovie projects but not Final Cut Pro 7 projects, the "iMovie Pro" designation seems somewhat appropriate.
It may seem so...
But, the iMovie Project/Event structure is a subset of the FCPX structure -- so relatively easy to import.
FCP structures as we know them can be very complex -- to name a few:
-- multiple tracks
-- multi-layer compositing
-- many supplied and 3rd-party filters, effects, etc.
-- different overall structure (Project, Sequences, Bins)
-- loosely defined and enforced structure
-- much more granular control
FCP as we know it is much more flexible -- but this has costs.
I suspect that Apple and/or 3rd parties will provide tools to migrate many FCP projects to FCPX.
One of the exciting things about FCPX is its performance -- use of all CPU/GPU cores, top priority UI with background importing, transcoding, analysis. The background pauses/resumes as needed to maintain a consistent UI experience -- avoiding the beach ball if at all possible.
This is accomplished by very savvy design and implemented using OpenCL and GCD to exploit the OS and hardware to deliver the best possible user experience.
FCPX is the first Apple app (that I have seen) to do this -- it may be the poster child for a new type of app.
And, therein lies a problem -- how do you migrate FCP projects with a lot of stuff that doesn't even know about multiple CPU cores, let alone OpenCL and GCD?
For example I have a 3rd-party Karaoke plugin that does synchronized subtitles (optional bouncing ball).
How is FCPX supposed to import a project using that filter?
Even if it could import it, how does it present itself in the timeline vis-a-vis other FCPX clips?
Will this plugin force a render and wait for completion -- and destroy the UX?
Worse, will the clip just sit there as an unplayable/scrubbable slug?
I have another sequence that has a five-layer video composite using FCP built-in masking constructs -- same questions as above.
Now, you might say "AHA, FCPX doesn't have the compositing capability of FCP7".
Maybe so, and maybe no...
FCPX provides some basic compositing, but relies on the new $50 Motion for any heavy lifting!
Why? Because Motion has compositing capabilities well beyond anything that FCP ever dreamed of -- and no constant re-rendering.
The new Motion has a much closer relationship with FCPX than the FCP7-Motion combination.
The new Motion has all the OpenCL GCD stuff designed and built-in.
Aside: Some have complained that FCPX doesn't handle Adobe multi-layer .psd files. This is true -- but it doesn't need to Motion handles them quite well and very efficiently. ping
I don't know the correct approach, here:
-- Should Apple supply a best-effort FCP7-FCPX project migration tool?
-- Other than point out "won't migrate" slugs, what should Apple do about things that it can't handle.
-- Should they leave legacy projects to be processed by legacy apps running on legacy OSes on legacy hardware?
This is a tough question for "Pros" or anyone with a library of Projects (of whatever app).
Some day you will move to the Latest/Greatest app -- be it FCPX, Avid, Adobe, whatever.
What do you do about your library of projects -- that suddenly, are now "Legacy Projects"
Do you spend your own time to convert them (at your expense)?
What do you do to compensate for features/filters/plugins that are not available on the new system?
Do you try to maintain those legacy apps/plugins, OSes, hardware -- so you can go back in a few years and update a client's animated logo (or somesuch)?
If you do, will you even remember how to use those "Legacy Tools" that you haven't touched for years?
What do you tell the client?
Maybe, some thought and effort needs to be spent finding a way to "encapsulate" your work so you can move forward without the shackles of "Legacy Tools".