Since you put this under scripting, are you doing this with a script? If yes, just put the offset in the script. If you have a window for the script, put a box where you can enter the timecode offset. Then, instead of changing the timeline start time, just add to the timeline normally - minus the offset you put in the box.

j-v, thanks, I tried this also, but it shows the same behavior:
The timeline offset is added to the TimecodeIn position of an event, though the shown "Timecode In" position in the media pool doesn't change.

So setting the timeline start position to 10:00:00:00 sets the TimecodeIn of the event to 20:00:00:00 instead of keeping the original 10:00:00:00. Makes no sense for me, but that's the way it is...

Nils

That's not what I'm saying. I'm saying if the recording started at 10:05:00:13, then add an offset in the script to subtract the 10:00:00:00 so that it is actually placed on the timeline at 5:00:13.

Let the SCRIPT do the offset. Leave the timeline alone.

Since you put this under scripting, are you doing this with a script? If yes, just put the offset in the script. If you have a window for the script, put a box where you can enter the timecode offset. Then, instead of changing the timeline start time, just add to the timeline normally - minus the offset you put in the box.

Yes by script. If I cannot find a solution for changing the timeline start, I will do it this way, but then the event timecode will not match the timeline timecode reading anymore. That's what I wanted to have, like in MediaComposer.

Nils

Well... you could add them all to the timeline as I was saying above and then change the timeline to start at "10:00:00:00" and then they should all match.

Well... you could add them all to the timeline as I was saying above and then change the timeline to start at "10:00:00:00" and then they should all match.

You are right, but I would loose the ability to resynch all events to timecode from time to time to correct for unintentional shifting of events on the timeline. All A/V streams need to stay consistent to their timecode position.

I think, the best workaround is to shift all events by the amount of the first event's media TimecodeIn. I will not have the same TC readings, but I can resynch anytime. I didn't found a function to only lock the media stream in time and only let the event boarders being movable.

Though, I'm a bit disappointed that Vegas disregards timecode workflows so much, claiming to be a professional tool. As soon as you have sound or multiple cameras you will need timecode.

Nils

Ok, If the events are placed at the timecode location I'm not sure why you'd need to "resync" as they're already where they're supposed to be. I suppose if new ones were added, that could become an issue.

How about this... Using the offset, have the script go set a "custom timecode" for each piece of media setting the timecode to be the original timecode minus the offset and turn on the "custom timecode" option.

Yes using "custom timecode" is a nice idea. It might also work to define a custom, project wide "negative timecode offset", stored e.g. in the "project comment". This offset (if there) is always used, when a new event is added to the timeline (or a resynch is needed), to compensate for the time-of-day shift.

Nils

Why wouldn't you set the timeline timecode before you add your source material?

Why wouldn't you set the timeline timecode before you add your source material?

That's what I was doing, but whenever the timeline offset was > 0, the event positioning was not at the TimecodeIn position anymore: the timeline offset was added to all absolute TC positions.

So, my foolproof workaround for this now is, whenever a do absolute timecode based event positioning in a script, I use "TimecodeIn - Ruler.StartTime" instead of "TimecodeIn" only.
"TimecodeIn - Ruler.StartTime" leads to a correct position (timeline reading = TimecodeIn) of the event in any case, independently from the timeline offset. And the default offset (0) still works too.

Though, I'm still wondering if this behavior is a bug or a feature. Seems more like a bug to me, as I cannot imagine a situation where this could be useful.

Nils