Set timeline start time without changing project start time possible?

NoKi wrote on 2/11/2023, 5:45 AM

I have many media with time-of-day timecode that need to be positioned at their original timecode position on the timeline. Problem is, when an event e.g. starts at 10:00:00:00 there are 10 hours of empty space before the event on the timeline. Not very handy, so I want to get rid of this offset, but keep the events at their original timecode position.

Setting the timeline start with "Project.Ruler.StartTime" to 10:00:00:00 does not help, as the event TimecodeIn is mapped to 20.00:00:00 now. So, when changing Ruler.StartTime all project timecodes are shifted as well, which makes this function useless for me. I would have to recalculate all event TimecodeIn values, which is not an elegant solution at all.

Is there any way to just set a ruler start offset without effecting the project's timecode reference? Hard to avoid free-run or time-of-day timecode if you want to record video and audio simultaneously, so this function would be very useful.

Thanks,
Nils

Comments

j-v wrote on 2/11/2023, 6:55 AM

You mean this?

met vriendelijke groet
Marten

Camera : Pan X900, GoPro Hero7 Hero Black, DJI Osmo Pocket, Samsung Galaxy A8
Desktop :MB Gigabyte Z390M, W11 home version 22H2, i7 9700 4.7Ghz,16 DDR4 GB RAM, Gef. GTX 1660 Ti with driver
537.42 Studiodriver and Intel HD graphics 630 with driver 31.0.101.2125
Laptop  :Asus ROG Str G712L, W11 home version 22H2, CPU i7-10875H, 16 GB RAM, NVIDIA GeForce RTX 2070 with Studiodriver 537.42 and Intel UHD Graphics 630 with driver 31.0.101.2125
Vegas software: VP 10 to 21 and VMS(pl) 10,12 to 17.
TV      :LG 4K 55EG960V

My slogan is: BE OR BECOME A STEM CELL DONOR!!! (because it saved my life in 2016)
 

jetdv wrote on 2/11/2023, 7:57 AM

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.

NoKi wrote on 2/11/2023, 8:01 AM

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

jetdv wrote on 2/11/2023, 8:06 AM

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.

NoKi wrote on 2/11/2023, 8:06 AM

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

jetdv wrote on 2/11/2023, 8:10 AM

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.

NoKi wrote on 2/11/2023, 8:23 AM

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

jetdv wrote on 2/11/2023, 8:32 AM

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.

 

NoKi wrote on 2/11/2023, 8:46 AM

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

DMT3 wrote on 2/11/2023, 4:43 PM

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

NoKi wrote on 2/12/2023, 4:29 AM

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

DMT3 wrote on 2/12/2023, 8:41 AM

Okay, I guess the issue is that Vegas is syncing timecode based on relative as opposed to absolute. That is strange.