FORUMS: list search recent posts

FCPX and time code

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Herb Sevush
FCPX and time code
on Oct 21, 2012 at 9:59:08 pm

Just curious, can FCPX manipulate time code the same way FCP Legacy can - can you change a clip's code, the drop frame vs non-drop flag, and enter values for AUX time code for clips that will permanently change the clip's metadata?

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Devin Crane
Re: FCPX and time code
on Oct 22, 2012 at 12:47:29 am

Nope. You can only change the timecode of the timeline.



Return to posts index

Bill Davis
Re: FCPX and time code
on Oct 22, 2012 at 2:48:59 am

Herb,

The entire X construct is that on import everything gets located and sequestered. So nothing EVER affects the underlying data. Every single editing operation, color correction, tag or change from that point on is essentially handled by applying new metadata on top of the old.

So while you can never change the timecode of an asset like a core footage clip - you can easily simply calculate whatever expression of timecode that you need to work with and have X display that one for you rather than the original.

When you create a project - it goes into the Project Library. If you then select it there, you can click on the "wrench Icon" in the Info tab and enter a starting offset timecode that will attach to the project and become that particular projects default. You can also enable or disable drop frame numbering in the same menu.

Since it's project based, you can make as many duplicates of the project as you like and set up as many timecode variations as you like.

Again, it's all just metadata layered on top of the original metadata.

So essentially, X lets you set the timecode parameters of each "expression" of your project as you like.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.


Return to posts index


Herb Sevush
Re: FCPX and time code
on Oct 22, 2012 at 4:44:58 am

[Bill Davis] "When you create a project - it goes into the Project Library. If you then select it there, you can click on the "wrench Icon" in the Info tab and enter a starting offset timecode that will attach to the project and become that particular projects default. You can also enable or disable drop frame numbering in the same menu."

I'm not interested in setting project timecode, I'm interested in changing the source timecode of individual clips.

[Bill Davis] "So while you can never change the timecode of an asset like a core footage clip - you can easily simply calculate whatever expression of timecode that you need to work with and have X display that one for you rather than the original."

The specific application would be to sync up a set of clips and then create timecode for them that would keep them in sync - I do this all the time in FCP and it comes in very handy. So your saying there is some way to create this off-set timecode for each individual clip, and this new code will stay with the clip as long as it's within FCPX?

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Mathieu Ghekiere
Re: FCPX and time code
on Oct 22, 2012 at 9:10:33 am

No there isn't (to my knowledge), and I've sent Apple Feedback a couple of times about this. I advise you to do the same, so they know I'm not the only one asking for better timecode support ;-)

What about having
- LTC on an audiotrack supported?
- Having a Timecode Viewer /HUD like we had in the Viewer/Canvas (I use this all the time to check if everything still is in sync!)?
- Being able to cut and copy timecode... The Dashboard now only allows you to manually put in timecode, but not copy it .So going to exactly the same timecode in FCP X now on different source clips is a pain right now if you have to do it a lot, and fast.
- Having a Timecode Reader/Generator Filter?

Let's hope the 10.0.6 update brings a lot of goodies... We are dependent on some of these features, and as long as FCP X doesn't have them, we can only use it to cut quick trailers and promos, but not for many of our bigger work.


Return to posts index

Oliver Peters
Re: FCPX and time code
on Oct 22, 2012 at 12:24:23 pm

I still use FCP 7 or QtChange to do these things. I also avoid Import from Camera and use FCP 7 Log & Transfer to transcode camera files, like P2, C300, etc. I have far, far better naming control in Log & Transfer, precisely because it alters the media names.

Oliver

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


Return to posts index


Keith Koby
Re: FCPX and time code
on Oct 22, 2012 at 2:37:31 pm

You can change the timecode display from drop to non-drop for a clip in the inspector, under the settings view. You can also change other important clip attributes there like scan and alpha handling.

It would be nice to see a handle there for changing time code value (from first frame or current frame) or adding an additional tc track. Currently, we are using QT Edit from digital rebellion to do this instead of going back into 7.

It would be nice to have source time code overlays in the viewer like we had with 7. Maybe someone can do that with a plugin. I recall that you can do this on the timeline now with the playhead, but I don't remember exactly how at the moment.

Another important tc feature that I miss from 7 and would like to see put back is rp188 insertion into out bound sdi. (Timecode going out the sdi card so it can be viewed on a pani display or the like as a burn in overlay.)

This was probably easier to accomplish with 7 because it was using QT and the cards just interfaced with QT to read the tc and then inserted it into the sdi signal. Now the card would have to be provided this info from the application or core av or wherever video comes from now.

From a production standpoint, TC is really important obviously. I would love for the tc display to be resizable/detachable/floating again.

Also, I see a number of editors who have a disconnect from the event library browser while skimming/playing/setting i/o, to the time code display, and then to the viewer. When you are setting ins and outs, on a source, your eyes are split to 3 screen areas, where you used to just have one area: the viewer. So I'd love for the second viewer to be back and some kind of better method for setting ins and outs to be included in a future release. I'm not saying make it just like 7, because the playhead slider wasn't the best navigation tool on a long clip either. But it's pretty clear the problem is deciding where you are supposed to look - the thumbnails where you are setting your i/o markers, the viewer (where you should be looking at the video, or the tc window - where you may need to focus for entry.

I'm dying to see if they've corrected this stuff in the next version. It seems to be all fixable maybe except the sdi tc which needs aja and bmd. When you put some of the above tc display issues together with the inability to retain an in and out selection in the event library when you click off to another area, you can get frustrated pretty quickly.

Keith Koby
Sr. Director Post-Production Engineering
iNDEMAND NETWORKS
Howard TV!/Movies On Demand/iNDEMAND Pay-Per-View/iNDEMAND 3D


Return to posts index

Mark Dobson
Re: FCPX and time code
on Oct 22, 2012 at 4:21:23 pm

[Keith Koby] "It would be nice to have source time code overlays in the viewer like we had with 7. Maybe someone can do that with a plugin. I recall that you can do this on the timeline now with the playhead, but I don't remember exactly how at the moment."

Great reply Keith and fingers crossed these basic, unglamorous, TC failings will be addressed in the next or subsequent update. It's these sort of things that really stop FCPX being taken up by many professional editors.

As to how you get a temporary glimpse of the source timecode:

Richard Taylor gives a really clear explanation.

http://fcpx.tv/tips4.html


Return to posts index

Marcus Moore
Re: FCPX and time code
on Oct 22, 2012 at 5:00:28 pm

I wonder if this kind of thing would be best executed with a HUD display, like in Motion or the Keyword overlay?



Return to posts index


Keith Koby
Re: FCPX and time code
on Oct 22, 2012 at 7:00:38 pm

yeah that would be a good use of the HUD.


Return to posts index

Bret Williams
Re: FCPX and time code
on Oct 22, 2012 at 6:37:30 pm

I didn't see any mention of the obvious clip skimming. cmd+option+s will skim clips individually if you're mousing over them in the timeline, and show their TC in the tc window.


Return to posts index

Bill Davis
Re: FCPX and time code
on Oct 22, 2012 at 6:05:41 pm

[Keith Koby] "When you put some of the above tc display issues together with the inability to retain an in and out selection in the event library when you click off to another area, you can get frustrated pretty quickly."

Huh?

That's EXACTLY what a range select then favorite or otherwise tag it operation does. It creates a persistent in and out selection in the event library.

This is the entire central core construction of the Event Browser in a nutshell - and you're saying that it doesn't do it?

Wow.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.


Return to posts index


Franz Bieberkopf
Re: FCPX and time code
on Oct 22, 2012 at 6:34:42 pm

[Bill Davis] "That's EXACTLY what a range select then favorite or otherwise tag it operation does. It creates a persistent in and out selection in the event library."

Uh oh ...

Here we go again.


Return to posts index

Oliver Peters
Re: FCPX and time code
on Oct 22, 2012 at 6:46:36 pm

[Bill Davis] "That's EXACTLY what a range select then favorite or otherwise tag it operation does. It creates a persistent in and out selection in the event library. "

That's an extra and unnecessary step, when you simply want to temporarily hold selected in/out points, as you review a few takes and go back-and-forth between them. I've done the ranged-based favorites, too. But... The other day I was moving quickly among a few clips and really found the lack of persistent ins/out (holding the last points selected) as making this operation a lot slower (and more frustrating) than other NLEs.

I view ranged favorites as the equivalent to subclips, not persistent ins/outs. I generally don't subclip in other NLEs, as it's usually unnecessary there.

- Oliver

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


Return to posts index

Keith Koby
Re: FCPX and time code
on Oct 22, 2012 at 6:47:32 pm

Uh no Bill, that's not at all what I'm saying. It does have persistence when you make it a favorite or tag it. And that is how I'm telling my editors to work around the problem.

What I'm pointing out is that if you set an in and an out on a clip in the event library, and don't make it a favorite, and then you navigate away to something else (the timeline for example to check something - like timecode), when you navigate back to your clip, your in and out is gone and you have to start over. In 7, you can set an in and an out in the viewer of a clip from the browser, you can do whatever to another clip and come back to your original one in the browser, open it to the viewer, and the ins and outs are still there. It's kind of convenient for editing.


Return to posts index


Bret Williams
Re: FCPX and time code
on Oct 22, 2012 at 6:47:45 pm

Others take their "Favorites" a bit more seriously. Not just an in and out they might use. One, Favorites, is used in logging, the other, persistent ins/outs, is a temporary thought about a clip, maybe even a subset of the "favorite." It's kind of irritating that you can't mark a quick in/out (and not put it in your favorites, cuz you don't know if it IS a favorite yet) then look at another possible choice, and then try to come back to it to find the marks are gone. AND, if you do use favorites, it better not overlap another, because it will get joined with the other, making the favorites technique for this particular application even more pointless.

That said, I understand why there is only one range ever at a time. in X there isn't a viewer. We don't edit from a viewer. The entire bin/event is the viewer. When you press Q,W,E it grabs from the range. If multiple clips had ranges, there'd be no way to know which one.

My guess is that implementation of a viewer will facilitate persistent ins/outs. I think this issue is kinda like copy/paste was on the iphone. Apple kinda wrote themselves into a corner and they're trying to figure out the best way before they commit to a methodology. Perhaps they could have some sort of range cache, where you can press a key while hovering over a clip, and it brings up the previous range you had selected. Kind of a behind the scenes not permanent favorite type thing.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 22, 2012 at 7:04:20 pm

[Bret Williams] "My guess is that implementation of a viewer will facilitate persistent ins/outs."

I think that getting PIOPs to work in FCPX is a lot more complicated than that.

PIOPs are properties of clips, but a lot of the objects that we interact with in FCPX are not actually clips; they are ranges which are not stored as objects themselves, but rather as references to objects.

What's the difference? PIOPs to clips is one-to-one; the PIOPs are stored with the clip. PIOPs to ranges is one-to-many; where do you store the PIOP? It can't go with the clip itself, as the clip may be referred to by many ranges, and it can't go with the range, because the range isn't real and may be defined by any of a number of overlapping methods.

Although I'm a PIOP fan and think that they are a worthwhile feature for an NLE to have, I think that they are collateral damage in the new FCPX data model. The best I would hope for now is that selection and deselection operations are pushed onto the undo stack so that clicking away from an un-favorited range could be undone so as to avoid destroying valuable user data.

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


Return to posts index

Oliver Peters
Re: FCPX and time code
on Oct 22, 2012 at 7:33:40 pm

[Walter Soyka] "I think that getting PIOPs to work in FCPX is a lot more complicated than that.

PIOPs are properties of clips, but a lot of the objects that we interact with in FCPX are not actually clips; they are ranges which are not stored as objects themselves, but rather as references to objects. "


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?

- Oliver

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


Return to posts index

Bill Davis
Re: FCPX and time code
on Oct 22, 2012 at 8:02:24 pm

[Oliver Peters] "I don't see temporarily holding a single PIOP on a clip as any different (code-wise) than writing a Favorite."

It seems like they ARE different to me. X is built around tracking changes to metadata. A "favorite" or any other tagged range is your decision baked into the metadata. A range selection, OTOH is just a temporary narrowing of the operators focus.

The difference is that one is permanent - the other ephemeral - and I get some want the temporary thing to be "conditionally persistent" but I can accept that there might be valid reasons why something which was trivial in the flat-file world, not being as trivial in a relational world.

Then again, what I know about programming is barely more than what I know about bandicoots.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.


Return to posts index

Oliver Peters
Re: FCPX and time code
on Oct 22, 2012 at 8:32:43 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


Return to posts index

Bret Williams
Re: FCPX and time code
on Oct 23, 2012 at 5:08:04 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.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 12:55:43 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


Return to posts index

Bret Williams
Re: FCPX and time code
on Oct 23, 2012 at 5:18:22 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.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 6:54:42 pm

Well -- PIOPs are here!

http://www.philiphodgetts.com/2012/10/final-cut-pro-x-10-0-6/

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


Return to posts index

Andrew Kimery
Re: FCPX and time code
on Oct 22, 2012 at 7:15:43 pm

Raise your hand if you are old enough to remember spending hours at the library with stacks of books doing research for a school paper.

Keep your hand up if you remember photocopying important sections from books so you could easily reference them later.

Keep your hand up if you remember how a book you were just reading would close automatically once you started reading a different book.

Wait, where did all the hands go?

Making a favorite is not the same thing as leaving I/O points set until the user explicitly removes them.




Return to posts index

Bill Davis
Re: FCPX and time code
on Oct 22, 2012 at 7:41:59 pm

[Andrew Kimery] "Making a favorite is not the same thing as leaving I/O points set until the user explicitly removes them."

No it's not. But as Walter concisely pointed out - in a conditional/relational construct like the database in X - stuff that worked great when clips were just a dumb thing in a bucket with a few simple things to connect to - just doesn't always function the same when the underlying organizing principals change.

Personally, I kinda think losing even a useful convenience like saving the operator two clicks (drag then favorite) to "save the state" of a selection, is a pretty small penalty for access to the huge power that having the solid beginnings of a real relational database bolted onto the editing engine in X provides.

I get that for editors who live or die on timeline operations, this is a hassle.

I just hope they can entertain the idea that the very same thing that makes this operation more difficult to code if Walters analysis is correct, simultaneously enables X to be a much better tool in some other areas.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.


Return to posts index

Andrew Kimery
Re: FCPX and time code
on Oct 22, 2012 at 8:14:09 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.




Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 22, 2012 at 8:28:48 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.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 1:04:01 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


Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 23, 2012 at 3:41:08 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.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 5:20:56 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


Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 23, 2012 at 1:40:50 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.


Return to posts index

Oliver Peters
Re: FCPX and time code
on Oct 23, 2012 at 2:15:50 pm

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

Going either direction is a problem, but even worse going from X to 7. IMHO, all translations from FCP X XML are at best a hack at this point. The information exposed to the developers is minimal and often requires them to "read the tea leaves" as to what Apple intended. At this point it's a very immature standard and often requires that media files are still online. For instance, if you need to be able to have reel numbers in an FCP 7 translation or an EDL (generated by EDL-X) that reel info is read directly from the media files by FCP 7 or EDL-X, as it's not passed through FCP X XML yet.

Oliver

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


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 7:08:30 pm

[Franz Bieberkopf] "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."

Continuing your translation metaphor, a literal translation is easy, but less valuable. An idiomatic translation is not so easy, but vastly more valuable.

I really don't see what the fuss is about. Apple more or less says that 7's data model doesn't contain all the information necessary for representing the edit in X's data model. Intelligent Assistance says attempts to make best guesses at what that missing data should be.

The two theses are perfectly compatible.

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


Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 23, 2012 at 7:28:42 pm

Walter,

... considering this was originally posted as a cheap shot a Apple regarding the persistent PIOP issue, it would seem the point of wit has been rather blunted.

Franz.


(It still raised an interesting and unexpected exchange though, and I am still rather surprised by your take - so I'd still like to hear you talk about project translations using other examples.)


Return to posts index

Keith Koby
Re: FCPX and time code
on Oct 23, 2012 at 7:34:39 pm

You thought my post that unfortunately derailed the thread regarding TC into a PIOP battle was a cheap shot? It wasn't intended as a cheap shot.


Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 23, 2012 at 7:46:36 pm

Keith,

My post was the cheap shot.

Franz.


Return to posts index

Keith Koby
Re: FCPX and time code
on Oct 23, 2012 at 7:53:07 pm

nice! sorry to derail anyways. it was a good TC feature discussion before. trying to download 10.7.5 so I can upgrade and dig on some PIOPs...


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 23, 2012 at 11:38:27 pm

[Franz Bieberkopf] "Walter... considering this was originally posted as a cheap shot a Apple regarding the persistent PIOP issue, it would seem the point of wit has been rather blunted."

My apologies. I don't know if I was being dour or just plain dense, but it whooshed right over my head...


[Franz Bieberkopf] "(It still raised an interesting and unexpected exchange though, and I am still rather surprised by your take - so I'd still like to hear you talk about project translations using other examples.)"

There aren't really other good examples to use, because in general, project translation happens within the same linguistic family. Translating from Legend to Pr is pretty straightforward, because they both fundamentally represent the data in the same fashion. Translating from Legend to ProTools via OMF is pretty straightforward for similar reasons.

FCPX describes an edit with a totally different data set than other NLEs. This is perhaps more like translating between layer-based and nodal compositors, but I'll be the first to point out that you can represent a layer-based composite entirely with nodes, and a node-based composite entirely with (often duplicated) layers. However, just like with a 7toX translation, you'll get a project file that renders the correct output; just like with a 7toX translation, it's a very hard problem to provide organization within the project file that is meaningful to the user because some missing data must be guessed.

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


Return to posts index

Franz Bieberkopf
Re: FCPX and time code
on Oct 23, 2012 at 11:58:19 pm

[Walter Soyka] "... just like with a 7toX translation, you'll get a project file that renders the correct output ..."

Walter,

I think this speaks to my question. Restricting ourselves for the moment to the question of timelines, I'm speculating that most people would be satisfied with a timeline that looks the same on output (even with a few qualifiers), as well as replicating keys structures of the timeline, and would not expect it to look "as if it had been originally created in" the software in question. I think the underlying model is of less interest than the practical implications.

Again the OMF example - it is in some ways quite limited both in what it brings from the original project, and in the way it exploits the possibilities of the importing software (like ProTools), but it is a very useful translation nonetheless. One might even say "proper" (though limited).

The FCP7 to PProCS6 example might illustrate the point, because if you created a project in PPro you might exploit features not in FCP7 (like some of the audio features), where in FCP7 you would not use these features because they don't exist - therefore the project would not, strictly speaking look "as if it had been originally created in" PPro.

Where this may falter is - as you've pointed out above - the (significant) issues of organization outside of timelines.

I take it you feel there are translations (like FCP7 to PPro?) that fulfill the "as if it had been originally created in" criteria?

Franz.


Return to posts index

Walter Soyka
Re: FCPX and time code
on Oct 26, 2012 at 9:09:26 pm

[Franz Bieberkopf] "Again the OMF example - it is in some ways quite limited both in what it brings from the original project, and in the way it exploits the possibilities of the importing software (like ProTools), but it is a very useful translation nonetheless. One might even say "proper" (though limited).

The FCP7 to PProCS6 example might illustrate the point, because if you created a project in PPro you might exploit features not in FCP7 (like some of the audio features), where in FCP7 you would not use these features because they don't exist - therefore the project would not, strictly speaking look "as if it had been originally created in" PPro."


Let's go Chomsky. FCP7/PrCS6/ProTools/OMF/whatever have different surface structures, but the same deep structure.

FCPX is an anomaly. It has a different deep structure that cannot be expressed by the data structures in other applications.



[Franz Bieberkopf] "Where this may falter is - as you've pointed out above - the (significant) issues of organization outside of timelines."

With FCP7/FCPX, I think it also significantly falters at organization within the timeline itself -- and that's a big problem. If the translator doesn't guess the relationships right, then the editor can't exploit the magnetic timeline out of the box. Magnetic maneuvers will work exactly as the timeline reads, but garbage in, garbage out.

It's the difference in organizational structure -- on a deeper level than differences in features -- that makes FCP7 to FCPX translations so hard.



[Franz Bieberkopf] "I think this speaks to my question. Restricting ourselves for the moment to the question of timelines, I'm speculating that most people would be satisfied with a timeline that looks the same on output (even with a few qualifiers), as well as replicating keys structures of the timeline, and would not expect it to look "as if it had been originally created in" the software in question. I think the underlying model is of less interest than the practical implications."

I agree with you that a "wrong" timeline that yields the right output is vastly more valuable than no ability to import legacy projects at all. Practically speaking, an imperfect translator is better than no translator, and I can only assume that the market is proving that with Intelligent Assistance products.

I said "as if it had been originally created in," but I meant that to be very specific to FCPX, because an FCPX edit is so built differently in terms of method and stored differently in terms of structure than an output-identical Legend edit. My phrase has less meaning for me with ideologically similar software.

I think that Apple chose not to pursue a translation feature because by definition, it cannot be perfect, and because an imperfect translation would make the magnetic timeline feel broken.

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


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]