can you lock track keyframes to events?

Mindmatter wrote on 3/24/2019, 4:21 AM

Hi all,

like the title says. Unless there's some sort of mismaneuvring on my part, it seems that moving things with ripple edit sometimes doesn't include the track motion keyframes ( but strangely, sometimes it does). I ran into this issue several times in a current project, where FX parameter key frames at track level did not follow the large moves made via ripple edit affecting all tracks , markers etc. But each time I specifically tested it by moving stuff and observing the keyframe lanes, it worked... so i wonder what made them not work on the other occasions?

I know we can lock the curves to events, but to my knowledge, there's no such function for the track motion keyframes. Is there a hidden function for that?

Thanks!

Comments

EricLNZ wrote on 3/24/2019, 4:52 AM

Possibly your problems occurred when rippling caused the keyframes to get out of order. This can occur if a keyframe jumps ahead of a previous keyframe because the previous keyframe doesn't move as it's before the edit point. Hope this makes sense.

Mindmatter wrote on 3/24/2019, 5:24 AM

Thanks Eric, that does make sense.In this particular situation though, the relation in between the keyframes remained intact, the whole bunch just didn‘t move with the moved track.

Marco. wrote on 3/24/2019, 5:49 AM

Try if setting the new ripple logic to "false" would help. I always set this one to "false" because the new ripple mode does not behave the way I'd expect. It's in the internal preferences.

Also be sure to set a keyframe which is meant to be at the very end of an event to 1 frame before the end.

Then you also have the choice to use the option "Lock Envelopes to Events" which works independently from the ripple-mode (but which also needs to take care of putting a keyframe onto the end of an event means putting it one frame before the event's edge).

Dexcon wrote on 3/24/2019, 6:12 AM

@Marco. Re setting a keyframe 1 frame from the end, I've been curious for some time as to why keyframing in pan/crop extends 1 frame beyond the end of the event, which is then a black frame. This is especially noticeable when using the 'sync curser' mode. Do you happen to know if there is a reason why this occurs?

No worries if the reason isn't known, but I'll certainly follow your recommendation in future to set the final keyframe 1 frame from the end of the event when I need to set a keyframe at the end of an event.

Marco. wrote on 3/24/2019, 8:04 AM

"I've been curious for some time as to why keyframing in pan/crop extends 1 frame beyond the end of the event, which is then a black frame."

This sounds like being one of the issues of a former bug which occured in previous builds when frame grids did not match. Does this still happen in VP16 latest build 361.

Mindmatter wrote on 3/24/2019, 9:53 AM

Marco, once again, you are a sheer limitless source of knowledge and help. thanks so much for your constantly tuning in and helping me with my issues and questions! I'll try that setting. I actually have "Lock Envelopes to Events" alwas on, but it didn't help in this case. It might have to do with the last frame thing you mentioned.

@Marco and Dexcon, yep indeed, it's there and seriously annoying. I was going to mention it next. When you click on " last keyframe" , the cursor goes to the end of that last frame and shows a black screen, making it impossible to reposition anything.

Dexcon wrote on 3/24/2019, 5:51 PM

@Marco.

Does this still happen in VP16 latest build 361.

Yep, it still happens in VP16 b361. Interestingly, all is okay within the pan/crop window when the pan/crop keyframe cursor is at the very end of the pan/crop timeline (for want of a better description). But that very last frame is black in the Preview window. An example is below:

Marco. wrote on 3/24/2019, 6:00 PM

This is expected behaviour. The timeline cursor will show the upcoming frame which is a gap with no video in your case.

For the Pan/Crop keyframe control it would be more logical if the cursor could not be set onto the right edge but rather would stop 1 frame before.