sequencer and camera

[Reindeer]

Hi. When I use the sequencer to reorganise the timing of my layers (or groups of layers), I later need to select and drag the camera keys to match the new situation.
Is there a way (or a trick) to lock the camera to a layer ora group of layers so that by dragging them I also drag the camera keys?

[Greenlaw]

Instead of using Sequencer, you could Consolidate the keys and re-time them that way. This way, the camera keys become part of the consolidation.

I usually find Consolidate Layer Channels works better for retiming since you can work with the keyframes directly. Just make sure you've set freezes at the ends of where you might want to squash or stretch ranges keys. This should prevent interpolation errors from being introduced.

[Reindeer]

Instead of using Sequencer, you could Consolidate the keys and re-time them that way. This way, the camera keys become part of the consolidation.I usually find Consolidate Layer Channels works better for retiming since you can work with the keyframes directly. Just make sure you've set freezes at the ends of where you might want to squash or stretch ranges keys. This should prevent interpolation errors from being introduced.

Yes that works nicely, thank you. I wonder why Consolidate Channels can't also work in conjunction with Sequencer. I mean, one is still just dragging chunks of keys in either mode.

[Greenlaw]

Sequencer doesn't actually move any keys, it's literally offsetting the entire layer, including frame 0. I generally avoid it because it can get confusing if you're still editing the animation and the setup frame itself. Plus, you're limited to only offsetting the entire animation in that layer, and no actual retiming of events.

I especially dislike Sequencer when the layer is accidentally offset by using Shift-Right drag. That can cause you to accidently add keys before frame zero, which, IMO, is a bad idea most of the time. I rarely do that anymore but some of the newer Moho animators at work will sometimes do this by accident, which can mess up their animations.

To be fair, there have been times where I found sequencer to be a super quick shortcut for offsetting duplicate cycling animations. But I have to be very sure I want to do that because I may be giving up some flexibility by not doing this on the normal timeline.

[Reindeer]

Sequencer doesn't actually move any keys, it's literally offsetting the entire layer, including frame 0. I generally avoid it because it can get confusing if you're still editing the animation and the setup frame itself. Plus, you're limited to only offsetting the entire animation, and no actual retiming of events.
I especially dislike Sequencer when the layer is accidentally offset by using Shift-Right drag. That can cause you to accidently add keys before frame zero, which, IMO, is a bad idea most of the time. I rarely do that anymore but some of the newer Moho animators at work will sometimes do this by accident, which can mess up their animations.
To be fair, there have been times where I found sequencer to be a super quick shortcut for offsetting duplicate cycling animations. But I have to be very sure I want to do that because I may be giving up some flexibility by not doing this on the normal timeline.

True, I do find Sequencer confusing insomuch as frame 0 is concerned. I have never quite figured out what happens to frame 0 when you move a layer. it gets offset but at the same time it doesn't look like it preserves its typical frame 0 functions. Let's say that by shifting a bone layer my new frame 0 is on frame 50, I've found that bone rigging changes in that adding and editing bones on frame 50 (my now new frame 0) adds key frames instead of leaving it neutral (as it would on my true frame 0). So, I actually like the Sequencer because it lets me offset cycles (as you said) and create pseudo-scenes (by offsetting entire groups of layers), but yes, it is confusing.

[Greenlaw]

I wonder if there are any useful reasons to keyframe before zero after slipping the timeline in Sequencer. I've never actually tried that on purpose.

[slowtiger]

I only use the sequencer for one purpose: when I build cycles and multiply objects after animating, then I use the sequencer to offset them from each other.

[Greenlaw]

Coincidentally, I'm working with a file right now where the animator had shifted a character's entire animation using Sequencer. It looks like regardless of which layers have been shifted with Sequencer, frame 0 (the setup frame) is always frame 0.

At first, the scene was puzzling to me because I see a bunch of keyframes at frame 38, which is where frame '0' would be after the time shifting. But after a bit of fiddling with the scene, it's clear that the actual setup frame is still at frame 0 and hasn't moved at all. I guess these keyframes exist at frame 38 to hold the position of the animation, so you don't get unwanted interpolation between frame 0 to 39.

In this case, I'm guessing it's okay to create keyframes between frame 0 - 39. But if you decide to shift the layers back to frame 0 using Sequencer, you'll probably want to delete those keys rather than sending them past frame 0, just so they don't cause unwanted interpolation or other keyframing problems.

Anyway, just sharing my observation to anybody who is still interested.

[Reindeer]

At first, the scene was puzzling to me because I see a bunch of keyframes at frame 38, which is where frame '0' would be after the time shifting. But after a bit of fiddling with the scene, it's clear that the actual setup frame is still at frame 0 and hasn't moved at all.

Yes that's precisely what I meant about the zero position being confusing. I too am under the impression that 0 stays where it should regardless of where your layer's time starts and that everything between 0 and start is sort of "no man's land". But I think I've come across situations in which this apparent rule is contradicted. In vector layers, for example, the shifted frame 0 tends to work (as far as I can tell) like the 'real' frame 0. Changes in points will not produce keyframes, just like 'real' frame 0 would. But then, bones, apparently incoherently with that assumption, instead seem to place keyframes on the shifted frame 0.