VEGAS TimeWarp - strange behaviour

Jack S wrote on 8/7/2019, 6:06 AM

Firstly, has anyone noticed that this is called TimeWarp in the list of Video/Media FXs when selected from the media/video event but, when selected from the Video FX tab it's called Slow Motion?

Secondly, has anyone checked out this effect after dragging out the event to reflect the slowed down event? I've slowed down a 4 second event to 25 percent of the original. Unless my math is way off (and no doubt I'll be corrected if it is) that should result in a new media event of 16 seconds. I dragged the original event out to a total length of 16 seconds and rendered it out. The resulting clip played out OK then, at about the 8 second mark, it jumped back to about the 4 second mark. Then, at about the 8 second mark, it jumped back again.

Am I going about this wrong? Can someone do a similar test please?

Comments

Marco. wrote on 8/7/2019, 6:22 AM

"Firstly, has anyone noticed that this is called TimeWarp in the list of Video/Media FXs when selected from the media/video event but, when selected from the Video FX tab it's called Slow Motion?"

Try deleting the folder "17.0" at the path:

C:\Users\<your user name>\AppData\Local\VEGAS Pro\

Next time you start VP17 Vegas Pro will recreate the folder "17.0" and this could solve the naming problem.

vkmast wrote on 8/7/2019, 6:27 AM

Firstly, has anyone noticed that this is called TimeWarp in the list of Video/Media FXs when selected from the media/video event but, when selected from the Video FX tab it's called Slow Motion?

Yes. See some comments on this here.

edit: @Marco.'s quick:) (And >100 comments since the VP 17 release, also from @fr0sty. 👍 both of you)

Marco. wrote on 8/7/2019, 6:41 AM

To the core problem. I see what you mean. The slomo fx does not update the new media length thus resulting in either looping or freezing at the end of the source media length. Looks like this needs an update for the slomo fx.
I see if I can find a workaround meanwhile.

matthias-krutz wrote on 8/7/2019, 8:24 AM

As a workaround you can turn off loop in the event properties. The notch on the top edge remains, but the entire event can be displayed if the event is dragged on longer.

Marco. wrote on 8/7/2019, 8:48 AM

This does not work for me. If I turn off looping (actually I've set this off in the preferences as my default), there will be a freeze frame after the source length is reached.

You would not see the issue if you keep the Video FX window opened. You have either to close that window before or render the timeline.

matthias-krutz wrote on 8/7/2019, 9:31 AM

For me it seems to work without problems. I have not seen a freeze frame here yet and I'm very happy with the result. Nice is also the keyframing for the playback rate. Unfortunately, dyn RAM preview (shift - B) does not work with slomo fx.

Jack S wrote on 8/7/2019, 9:59 AM

Marco

Try deleting the folder "17.0" at the path:

C:\Users\<your user name>\AppData\Local\VEGAS Pro\

Next time you start VP17 Vegas Pro will recreate the folder "17.0" and this could solve the naming problem.

Thanks a lot. All 3 instances now show the name as 'VEGAS Slow Motion'.

One more question. How do you know all this stuff? 🙂

vkmast wrote on 8/7/2019, 10:03 AM

@Jack S he just does 🙂. (Sometimes devs may help)

Former user wrote on 8/7/2019, 10:51 AM

Definitely artefacts though.

Jack S wrote on 8/7/2019, 10:53 AM

Thanks vkmast, for pointing me to that 'devs may help' thread. I had bought a new graphics card, GeForce GTX 1050 Ti (2 year old technology i know, but it was all I could afford), to take advantage of GPU acceleration but I wasn't seeing much improvement with a 10 minute project. I had enabled it and set NVIDIA NVDEC in the File I/O tab. This had got rendering time down from 21 mins w/o GPU to 15m 37s with GPU but I wasn't seeing any activity on the 'Video Encode' graph in Task Manager/Performance. After utilising the Magix AVC encoder with 'Encode mode' set to NV Encoder, the render time reduced dramatically to 8m 55s. I've now got to see whether DVD Architect will pass this through without re-compressing.

Once again, thank you.

Jack S wrote on 8/7/2019, 10:58 AM

JN_

Definitely artefacts though.

I did have a lot of artefacts, quite big ones too, before I enabled GPU acceleration.Now, I'm not experiencing them and, considering my source media is interlaced, the results are quite acceptable.

Marco. wrote on 8/7/2019, 11:01 AM

Does it mean it now works even beyond the length of your source media after you stretched the video event to match the slomo setting?

Jack S wrote on 8/7/2019, 11:32 AM

Marco

No, I was merely indicating to JN_ that I wasn't experiencing artefacts since enabling GPU acceleration. Like your experience, disabling Loop created a freeze frame after the source length.

Marco. wrote on 8/7/2019, 11:44 AM

I just reported this as a bug, though it seems not everyone can repro.

Marco. wrote on 8/8/2019, 5:35 AM

@Jack S
It seems like for now we at least found a workaround.

Try adjusting your event length before you apply, analyze and set the parameters of the Slow Motion FX.

I know this sometimes may be bit of hassle but at least in my case this works fine.
So for example if you have a timeline clip of 1 second length, drag the event length to 10 seconds. Then apply Slow Motion, analyze, set the slomo rate to 0.1 and render.

If that does not yet work, try also setting your RAM Preview to 0 (zero).
On my system I there's no need to do this (I have my RAM Preview set to 4096 most of the time) but it may happen the RAM could mistakenly buffer frames which then affects the slomo.

Now maybe someone else is willing to write an Extension which allows to type-in the value of the slomo rate (to be used in the Slow Motion FX later) which then would automatically adopt to the Event length.

Jack S wrote on 8/8/2019, 5:07 PM

Marco

Yes, that works for me, thank you. A strange workaround though, counter intuitive. That's what I call 'Thinking outside the box'.