TOPIC:

TIMECODE! Coremelt released a free source timecode plugin yesterday for FCP X. Happy Day! Someone finally figured it out and we didn't have to wait till Apple got around to it. It's customizable to have source or rec timecode along with position and scale controls. You can have it as just a visual overlay or burnt in for export. Works perfectly so far. Bravo to Coremelt for figuring it out!

You can get it in their free plugins installer: www.coremelt.com/download.html#free

Yay!

Not showing my source timecode properly. Offsets around 40 seconds but not consistent timewise. Don't have time to explore further right now.

Send that info in an email to Coremelt's support so they can take a look: This email address is being protected from spambots. You need JavaScript enabled to view it.

hmmm - first reaction"Finally, coremelt I want to marry you!!" (... not really). But this is my most-wanted feature!

...
//lots of pics - easier for me to show, than to tell://

In use here a consumer camcorder , AVCHD... on import we read:


rec time 4:27 (afternoon) ...

now an Event, applied to a Project; the plug-in notices TWO diff. times:


REC is the actual Project time ... we had that before.....
SRC is ... what? I would like to see my afternoon, 4:27, nope, 1:44 .. where is THIS time coming from?

In the Event browser same:


the skimmer-info is NOT the time of recording.

Answer:


.. not REC time (sunday afternoon), not Projject time, but each clips own ´timecode' - you see in my last screenshot: EVERY clip starts with 00:00:00

so, the plug-in doesn't show the 'timestamp' of recording,- Sad news

A while ago, I posted my work-around ... the rec-time IS in the files... well hidden, hard to read ...

...or, does coremelts plug-in work better with v10.2? Then forget this lengthy post ....
I still haven't updated, 'cause in the middle of some really boring, lenghty project .... -

..

It works properly in FCP X 10.2.1, which is what I'm running. Shows clip REC time not project timecode. Source timecode matches up for me between the timeline and the metadata in the info inspector.

Some further experience.

Multicam clips: It works perfectly, reaching inside to the source clips and displaying source and rec timecode.

Synced Clips: It's a yes and no answer. No, it won't reach inside to the source clip on synced clips like it does with multicam. When you create a new synchronized clip it asks you to input a starting timecode. So, if you give it the starting timecode of the source clip then you'll be fine. If not, it starts from 00:00:00:00. Probably has to do with the way FCP X was programed.

thefcpxeditor wrote:

It works properly in FCP X 10.2.1, which is what I'm running....

Great! Good news, makes me hope......
'til next weekend, I will update! (keen to see & test the new/improved Qptical Flow!)
....

two good reasons to update!

Have you tried using the TC-reader in a Motion project?
Ibuilt my own 'screen package', and it should display the Game-time



Would be great, if the plugin works in Motion projects too ....
(but needs some 'masking' no 'SRC', no 'frames'.... ) ... ahh, I see, this will be a busy weekend!

Karsten, the source timecode is set by your camera. In most cameras you can choose the start source timecode when you start recording and then subsequent clips will follow on from that. It is not connected to the time of day that you started recording on. I don't think that information is available to us, sorry.

This plugin will also not work in Motion, sorry.

CoreMelt wrote:

// full quote //

Many thanks, Roger, for chiming in!

aaand, poof!, hope gone …again… LOL!
I'll dig deeper in the manual of my FZ1000, if there's an option, to force the cam to create any bits&bytes, useful for showing the actual rec time (or 'game time' as I phrase it) .... I'm under the vague impression, I read about 'continous' time stamp...? .... anyhow....

The 'funny' part is, for me, as a total ignorant of engineering: the 'time stamp' is read by FCPX… my - inconvenient - workaround proofs it. grrrrrrr....

Anyhow: coremelt does magic, purchased lately (impossbile to regret your NAB special offer...) SliceX and TrackX ... still learning, but plain awesome!!!

Maybe, Karsten, you could make use of a synced clip as thefcpxeditor mentioned above? Where you can enter your own value of TC when creating it? Good luck!

Karsten,

The problem is that many if not most of the "modern" formats won't match the "old fashioned" QT format.
So for those modern ones the TC might be buried somewhere in the data structure and this will probably differ from codec to codec. This way Apple and others are in "Codec hell". The result is: make things easy, ignore some information, make them play real time.
If you would go to "optimized media" FCPX will be back on the old QT way. This means two things. Bigger files (no GOP). A QT container with several tracks like Video, Audio and TC (can be more tracks).
Having a dedicated QT TC track allows to modify it the way you want - it can be set to TOD, like in the examples you showed.
This was easy in FCP, FCPX doesn't allow any more. You need a dedicated app.

- Andreas

Great! Can't wait to give it a shot!

Thanks everyone, for your suggestions and participation.

I actually HAVE a working work-around (working work… wotelse, Schlüter?!!) , just folow the link in my postabove... apply a Motion-made 'title with an TC-reader as one of my MultiCam tracks; that's the kind of 'synched clip' you recommend...

… not very sexy my workaround...... inconvenient.

'No use in Motion' is no trouble, ... have some ideas to work-around the work-around

But step#1 first: updating,,,,

I post my results later here.......

Looks like Source Timecode is working properly now.