Keyframe at the end of events

matthias-krutz wrote on 5/18/2018, 3:49 AM

I often use event-level keyframes with a synchronized cursor. When I jump to the end of an event with CTRL-End, the preview does not show the last frame but already the first frame of the next event or it stays black if there is no next event.
To see the end in the preview, I have to place the keyframe a little before the end and push it to the end after work is done. This is very annoying and inaccurate.

I examined the behavior at an event with 3 frames length.

The problem is that one frame (range 0-1, 1-2, 2-3) is not assigned exactly one keyframe. Keyframes can now be placed at the beginning or end of a frame, at positions 0,1,2 and 3. In a 3-frame event 4 keyframes can be set, as the picture shows. The 4th keyframe (position 3) is wrong and already matches the next event on the timeline.

Logically, it would be to put the keyframes in the middle of the frames or only at the beginning.

Do you also see it like that?

Comments

NickHope wrote on 5/18/2018, 6:02 AM

I completely agree. I've always thought that it should not be possible to add a keyframe beyond the start of the last frame of an event. Maybe there's a use for it in some circumstances, but I don't know of one. Even if Quantize To Frames is OFF, a video parameter will not change within the duration that last frame, so a keyframe at the end is illogical and annoying. It's annoying because when the cursor is there, you're previewing either the next event or nothing, when you want to be seeing what's going on in this one.

There's also a quirk whereby if you repeatedly click the "Last Keyframe" button, it toggles the cursor position between the last keyframe and the end of the event. Makes no sense to me. Maybe the design intention was to provide a quick way to get the cursor to the end of the event without creating an extra button, but the Help doesn't refer to that, and it would be much better if those alternate clicks placed the cursor at the start of the last frame. Or I suggest adding a new button to move the cursor to the start of the last frame, and then permit the existing button to only do exactly what it says (i.e. move to last keyframe).

I think keyframes should remain at the start of frames, not middle. That's what everyone is used to, and that provides accurate behaviour of Sync Cursor when Quantize To Frames is ON.

matthias-krutz wrote on 5/18/2018, 10:59 AM

Sometimes keyframes are duplicated at the end of an event. The reason of this I can not say exactly. Could be that this is also related to a different (wrong) definition of the last keyframe. That's why I rather think it's a design flaw.

Yes, it is more logical to remain the keyframes at the start of frames, even though the last keyframe would not be at the end of the Keyframe Controller timeline.

john_dennis wrote on 5/18/2018, 11:16 AM

It took me a while to get accustomed to the key frame operation of the end of an event. If it changes it would probably catch me off guard, now. Here's the way I deal with it.

If you're trying to place key frames with frame level accuracy, you should be zoomed in. After placing the cursor a the end of the event, I hit the left arrow key one time.

john_dennis wrote on 5/18/2018, 2:16 PM

In spite of how stubborn my wife says I am, I would quickly sign up for a new navigation button that moved the cursor to start of the last frame of the event.

Red Prince wrote on 5/18/2018, 2:57 PM

While most of the time I want the end of the event to be the beginning of the last frame (and do what john_dennis does, go to the end of the event and press the left arrow key), there are occasions when it does make sense for setting a keyframe right after the last frame of the event, when I am using an effect to transition from some state to some other state, where the other state starts at the first frame of the next event. In that case I want to have the last frame of the event to still be in the state of change, so any of its animated parameters should still be just before the final state.

I am not sure I am being clear here, so let me illustrate. Suppose some parameter changes values between 0 and 1. In some situations I want its value at the last frame be just a bit short of 1, and I want the software (Vegas Pro in this case) to calculate its value based on the total number of frames in the event instead of me having to calculate it by hand. So, if there are 24 frames in an event, let us call them frames 0-23, I want the parameter at frame 0 to be 0 and at frame 23 to be 23/24 instead of 1. This can be easily accomplished if the end of the event is at the end of the last frame.

So to me, the way Vegas does it makes perfect sense.

NickHope wrote on 5/19/2018, 3:19 AM

That's a very good point Red Prince. That function would be lost if keyframes at the very end were abolished. For example I can certainly imagine increasing brightness from 0 to 1 across 2 equal-length events. If you made the brightness 0.5 at both the start of the last frame of the first event, and the first frame of the 2nd event, you'd end up with 2 frames at the same brightness instead of a smooth transition.

JD, your mockup of a new navigation button is exactly the sort of thing I had in mind.

matthias-krutz wrote on 5/19/2018, 6:22 AM

The example is good, although the use will be rather rare.
To consider is also the following:
if I push keyframes to the right end, they should snap to the start of the last frame and not behind it. If I wanted to use the very last keyframe, they have to let it move to the end. These are two different behavior of keyframes that should be set in the event or preferences. Then we did not need a new navigation button.

Status 1 - Last Frame (start of last frame)
Status 2 - Last Frame + 1 (the current behavior)

Red Prince wrote on 5/19/2018, 10:41 AM

Yes, of course, two different buttons would be nice. Or perhaps one button working differently with or without pressing it while holding the shift key or such.