Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations FCPX and time code

  • Andrew Kimery

    October 22, 2012 at 8:14 pm

    I agree that there is a lot of new and improved features in FCP X when it comes to metadata. I agree that Walter might be right in that given the underpinnings of FCP X it may not be capable of the PIOP functionality that is in Classic. I agree people should still recommend the PIOP functionality be added because if someone at Apple could figure out how to do it (w/o breaking other things in the process) it would be a handy feature to have around.

    The only thing I disagree with is when someone says a favorite in FCP X performs the same function only better.

  • Franz Bieberkopf

    October 22, 2012 at 8:28 pm

    [Andrew Kimery] “… if someone at Apple could figure out how to do it (w/o breaking other things in the process) it would be a handy feature to have around.”

    Andrew,

    Just keep in mind this is the software development team that said “there is no way to “translate” or bring in old projects [from 7] without changing or losing data.” and “FCP7 projects do not have enough information in them to properly translate to FCPX”.

    You may have more luck hoping for third-party development on PIOP.

    Franz.

  • Oliver Peters

    October 22, 2012 at 8:32 pm

    [Bill Davis] ” A “favorite” or any other tagged range is your decision baked into the metadata”

    No, I don’t think so. A favorite can be removed or altered, so it’s hardly “baked in”. The data is merely written into the database file as its current state, but that can be easily changed. It’s no more permanent than a street address entry in Address Book. I’m pretty sure that each and every one of us – except probably David L – is completely out of our league when we start talking about what can and can’t be done in the code (myself included).

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Walter Soyka

    October 23, 2012 at 12:55 am

    [Oliver Peters] “But why should that be the case? I don’t see temporarily holding a single PIOP on a clip as any different (code-wise) than writing a Favorite. Currently a single set of PIOPs is held when you stay with a clip and go back and forth between that clip and the project timeline. They are only lost when you go to another clip. Why not hold that in RAM or a state or cache file that’s flushed when you exit the app?”

    You’re preaching to the choir. I want PIOPs, and I want them to feel local or connected to the clip/favorite/keyword range just like PIOPs were connected to clips and subclips in Legend.

    However, in your example above, remember that you could be setting IOPs within not just a clip, but also a favorite or a keyword range. You need to attach that IOP to something so it can be recalled when you re-select it; in FCP Legend this was easy because there were only clips and very clip-like subclips; in FCPX it’s harder because favorites and keyword ranges are derived from clips but are not clips themselves (even though they are sometimes presenting to the user as if they were clips).

    I don’t really want to re-try the case, so I’ll point back to the last discussion on this instead — see your Editing Scenario thread [link].

    Here’s a good place to jump into the middle of that thread [link] where the PIOP fun begins, and it gets really good when Jeremy shares some pictures [link].

    Walter Soyka
    Principal & Designer at Keen Live
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    RenderBreak Blog – What I’m thinking when my workstation’s thinking
    Creative Cow Forum Host: Live & Stage Events

  • Walter Soyka

    October 23, 2012 at 1:04 am

    [Franz Bieberkopf] “Just keep in mind this is the software development team that said “there is no way to “translate” or bring in old projects [from 7] without changing or losing data.” and “FCP7 projects do not have enough information in them to properly translate to FCPX”. “

    But that’s absolutely true. FCP7 timelines do not encode clip relationships, and FCPX timelines are organizationally dependent on them.

    Just as there’s no way to derive the original image from a size-reduced version (because a number of originals would produce the same reduction), there is no way know if you’ve derived what would have been the original FCPX timeline from a Legend timeline as if it had been originally created in X in any 7 to X translation.

    What Mr. Hodgetts and Mr. Clarke have done is roughly analogous to interpolation for resizing images; you can size up and get an image that looks something like the original, but there’s no way to get the actual original back because the data you need is not available in your source.

    Walter Soyka
    Principal & Designer at Keen Live
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    RenderBreak Blog – What I’m thinking when my workstation’s thinking
    Creative Cow Forum Host: Live & Stage Events

  • Franz Bieberkopf

    October 23, 2012 at 3:41 am

    [Walter Soyka] “… there is no way know if you’ve derived what would have been the original FCPX timeline from a Legend timeline as if it had been originally created in X in any 7 to X translation.”

    Walter,

    Would this be an objective for anyone wishing translate a project from one NLE to another?

    Franz.

    Edit: … to provide a more pointed example – if I were to “originally create” a session in ProTools, it would have both stereo and mono tracks; an OMF from FCP gives me mono tracks only which have been panned. The translation does not give me a session in ProTools “as if it had been originally created” in ProTools. It would seem an absurd claim to say that “there is no way to “translate” or bring in” a project “without changing or losing data”, or that the original project does “not have enough information in them to properly translate”. Translation requires a change of data on some level (otherwise it is just an import).

    There is probably an entire thread to be had here on the nature of translation. Starting with Esperanto.

  • Bret Williams

    October 23, 2012 at 5:08 am

    Correct. If it was baked into the metadata, you could take your quicktime over to someone elses system and import it the favorite would still be there. It won’t.

  • Bret Williams

    October 23, 2012 at 5:18 am

    Here’s where I think the viewer helps. Say you opened the clip in a viewer. Now instead of a range, it could be defined as something else. Viewer range, in/out, whatever. It’s a different criteria like reject or favorite. It also introduces one more edit button or a modifier key to the current Q,W, and E edit functions. Those all edit from the current range. No matter where it is. There is, as we’re all realizing, only ONE location to edit from. The event. The range marks a spot in time in the event. Not in a keyword collection and not in a clip. If ranges (we should quit saying in and out becuase there really is no such thing in X, just ranges) could exist on multiple clips, then what range would the edit come from? A clip need not be selected to scrub and select a range.

    So, perhaps when one is in the upcoming viewer, in and out is actually marked. Not a range. This data is never revealed unless you open a clip in a viewer. And, you would need a new key to edit from the viewer (perhaps just a modifier to QWE) or a preference setting. Range editing or “classic style” editing. Ranges could still be placed in collections and edits from there could be still drag and drop. Pretty much the way FCP 7 worked, except actually with more, additionally powerful options. Win win. You could work the old way, or with a mix, or just the new way perhaps if you’re limited to a single screen or laptop.

  • Walter Soyka

    October 23, 2012 at 5:20 am

    [Franz Bieberkopf] “Would this be an objective for anyone wishing translate a project from one NLE to another?”

    In this case, I’d argue yes. Clip relationships are incidental and only implied in FCP7, but they actually form the structure of the edit in FCPX. If you don’t get the clip relationships or editorial intent right, then you have not translated the project into FCPX’s native language.

    (I do think that a great many people here would have been happy for a literal translation, even if it was filled with native-language malapropisms. I’d consider a path like this to be simply getting all the clips in order into the primary, or V1 to the primary and everything else to secondaries; incorrect assignments could then be manually corrected by the editor. Doing anything more than this gets enormously complicated very quickly, as Philip Hodgetts describes.)

    Walter Soyka
    Principal & Designer at Keen Live
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    RenderBreak Blog – What I’m thinking when my workstation’s thinking
    Creative Cow Forum Host: Live & Stage Events

  • Franz Bieberkopf

    October 23, 2012 at 1:40 pm

    Walter,

    I’m not sure you’ve really explained why this would be the definitive objective of an NLE translation – that “there is no way to translate” or a translation cannot be done “properly” unless “you’ve derived what would have been the original FCPX timeline from a Legend timeline as if it had been originally created in X in any 7 to X translation.”

    As I pointed out in my ProTools / OMF example above, I am not necessarily (ever?) looking for a translation to “look as if it had been originally created in” the new tool. Different tools are just that, and creating in them often brings different decisions or different ways of expressing those decisions (ie stereo tracks vs. stereo clips). It is one thing to present the limitations of a translation, quite another to say that it can’t be done.

    In any case – pixel interpolating metaphor aside – you seem to be implying by your argument that 7toX is not a “proper” translation.

    Franz.

Page 3 of 4

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy