Be VERY careful if you follow the advice given about stretching the picture events. Don't get me wrong, it is the correct advice, and is the same thing I would advise, but there is a great big "gotcha" (Vegas has a bug in it that they refuse to fix ).

Here's the bug: When you drag any event and make it longer, if you have created keyframes to move the pictures around (the "Ken Burns" effect), if there is a keyframe at the end of the event, then when you make the end of the event longer, that keyframe stays in the same exact place rather than staying with the end of the event. As a result, all of your events will cease to animate after the playback cursor gets to that point in the lengthened event.

I call this a bug because if you make the event longer by dragging the left edge of the event, then the first keyframe stays at the beginning of the event.

So, if you encounter the problem, now that you know what to look for, try moving all the events, once grouped, over to the right on the timeline, and then try stretching by grabbing the left edge of the first event.

Thank you very much Mike and John. It worked very well. You saved my life. You are awesome. Luckly there weas no keyframe. Thanks to both of you

>>...that keyframe stays in the same exact place
>>rather than staying with the end of the event...

To my knowledge, this has "always been that way." I've never seen Vegas behave any other way.

I can see where a keyframe could have a relative position ("at the end") versus an absolute position (00:00:03:13).

I know that in Boris Red, if you have keyframes on the timeline and you subsequently change the duration of the timeline, the keyframes maintain their relative positions. That is kind of handy.

I have not seen in Vegas, however, any reference to a relative keyframe position. All seems to be absolute. I guess that having Vegas keyframes maintain their relative positions would be kind of nice.

Would the keyframes be an issue if you nested the timeline in a new project and used the velocity envelope there?

Dave T2

I have not seen in Vegas, however, any reference to a relative keyframe position.I am not sure I made it clear.

Here are the keyframes before making the event longer:


Here are the keyframes after making the event longer by grabbing the end and lengthening the event:



Note that the second keyframe is no longer at the end of the event, and therefore the keyframe motion will cease after the second keyframe.

BTW, I just discovered a "trick" to get around this problem. What you do is press and hold the Ctrl key while stretching. In this case, the final keyframe DOES stay at the end of the event!! Then all you have to do is right click on the event, select "Properties," and then change the playback rate from whatever number it has changed to, back to one (1).

In my mind, this confirms my belief that this is a bug in Vegas, and not the result of a conscious design decision. Why would the final keyframe move when lengthening the event, but when you hold the control key to simultaneously also change the playback rate, the keyframe DOES stay at the end?? Weird.

I've always done the CTRL-Drag and never had any issues with keyframes. Why would you change the playback rate back to 1? If it's an image, it won't make any difference. If it's video, now you've suddenly added more footage you previously trimmed off. So I'm not seeing why you're changing the playback rate.

"Why would the final keyframe move when lengthening the event, but when you hold the control key to simultaneously also change the playback rate, the keyframe DOES stay at the end?? Weird."

The final keyframe doesn't move, it stays exactly where you put it. IF your Keyframe is at 3 seconds and you extend the length of the shot the keyframe still stays at 3 seconds. If you use CTRL which changes the speed of the shot, it stays at 3 seconds relative to the shot if it were running at normal speed. May not be the best, but that is the way it seems to work.

Dave T2

So I'm not seeing why you're changing the playback rate.

Wow, I am definitely having trouble getting this one across.

First, I DON'T want to change the playback rate, since that makes no sense for a still photo. I was just pointing out that if you make the still photo event longer by holding the Ctrl key, then the final keyframe stays at the end of the event, which is the behavior I consider to be the correct behavior. If you do the more normal and logical thing, which is merely to extend the event, then the keyframe stays at the same place, relative to the start of the event, and this means that all motion and animation of the still photo will stop once that keyframe location has been reached.

I run into this problem all the time when I am trying to time photos to music. To do this, I add or delete photos from the timeline, but I also make slight adjustments to the duration. I often do this AFTER I have created my photo moves. This is especially useful if the events are cross-faded and I want to change the duration of the crossfade.

While making the event slightly longer and keeping the keyframe at the end of the event without changing anything else does make the move go more slowly, this is usually not a problem. By contrast, having the motion halt abruptly is a HUGE issue, and if you are dealing with a few hundred images, it is very easy to forget to look and see if you have this problem. I eventually wrote a script that flags all events that don't have a keyframe at the end of the event (but only if there is more than one keyframe). It solves the problem for me, but not for most other people.

You can download and view below a Wink demo of what I am talking about. I spent zero time on this, so it is very crude, but note that the motion in the preview window ceases for the last five seconds of the video because the keyframe is now in the middle of the event rather than at the end.

Demo of Problem

Just drop the SWF file on your browser (or play it in your Flash player, if you have one).

This is why I think it works the way it does. Say you do a Zoom effect on a scene and you want the zoom to end on the beat of music. Now you decide to extend the scene but the music beat stays the same and you want the zoom to stop relative to the beat, then you are good to go.

I think there should be an option to stay relative or absolute.

Dave T2

I think there should be an option to stay relative or absolute.I agree 100%, and that is what I asked Sony to do several years ago.

I have a very large laundry list of keyframe problems, bugs and issues that I have written to them about for many years. I consider keyframes to be one of the most important features in Vegas, yet there are so many UI issues, quirks, and bugs that I often find myself spending integer multiples of the time it should take to finish a project. I just did a quick review of all the keyframe emails I have sent to Sony, and I counted 32 emails that have the word "keyframe" in them, most of which were central to the issue I was reporting.

First, I DON'T want to change the playback rate, since that makes no sense for a still photo. I was just pointing out that if you make the still photo event longer by holding the Ctrl key, then the final keyframe stays at the end of the event, which is the behavior I consider to be the correct behavior. If you do the more normal and logical thing, which is merely to extend the event, then the keyframe stays at the same place, relative to the start of the event, and this means that all motion and animation of the still photo will stop once that keyframe location has been reached.

Yes, but you'll also get the notch because you've gone past the length of the clip. I'm not following the objection to just holding down CTRL and resizing even if it IS a photo. You've still extended it, it will still render the same as lengthening it and moving the keyframe... THAT'S why I asked the question.

I understand what John is saying but I'm with jetdv,
If you want to preserve the motion you've created with keyframes you "stretch" everything, including the keyframes using ctl function. If you just want to add time, you don't. I've never considered this a bug at all - it seems intuitive to me... :)