make the GUI show if two consecutive keyframes are the same

[hayasidist]

very clear. I hope our discussion helps Wes when he gets around to implementation!

[synthsin75]

before getting too far into making this run automatically, remember there could be very many duplicates "intentionally" created by auto-freeze; also when considering the "all" or "selected" channel - if there are (e.g.) 3 points selected and ONE of them has the same value in successive keyframes, but not the others, what to you show?

Good question. I quickly tested how colors work and they seem to show the predominant color, so if the majority of bones have blue keyframes in that frame the general keyframes will look blue, and if the majority of the selected bones have blue keyframes in that frame, the "selected" red channel will show blue keyframes.

I think this "majority" behaviour is not ideal for this purpose. The user wants to know if *anything* changed that frame. So if something changed, even if the majority of the elements were unchanged, the keyframes should show that something changed. Only if every element (or every selected element) has the same values, the keyframes should show that they are the same.

If the native colored keyframe behavior won't work, then I'm at a loss on how else to implement this. You'd have to select every object (point, bone, etc.) individually in order to know if it was a duplicate key in the "selected" channel.

Mmm...I guess I could automate timeline markers, but that may disrupt their use more than colored keyframes. But at least those could be set ONLY when every key on that frame is a duplicate of the previous or frame zero values.

Thanks for the heads up, and if anyone has any better ideas, I'm all ears.

[Daxel]

If the native colored keyframe behavior won't work, then I'm at a loss on how else to implement this. You'd have to select every object (point, bone, etc.) individually in order to know if it was a duplicate key in the "selected" channel.

Mmm...I guess I could automate timeline markers, but that may disrupt their use more than colored keyframes. But at least those could be set ONLY when every key on that frame is a duplicate of the previous or frame zero values.

Thanks for the heads up, and if anyone has any better ideas, I'm all ears.

Yeah I guess we can't change how keyframe color showing works.

And the problem with timeline markers is that they mark frames, but not keyframes, so you could see duplicated frames but you couldn't see duplicated keyframes for one channel like bone rotation, or select specific items to see if their keyframes are duplicates or not.

[hayasidist]

What might be interesting is to transform a pair of identical keys into a hold. And have the opposite - IOW to take a hold key and make it no hold at start and add a key at the end (so that animation could be inserted)? not sure how that might work in a "multiple identical" situation though (e.g. as might be created by auto-freeze)

[synthsin75]

Yeah I guess we can't change how keyframe color showing works.

And the problem with timeline markers is that they mark frames, but not keyframes, so you could see duplicated frames but you couldn't see duplicated keyframes for one channel like bone rotation, or select specific items to see if their keyframes are duplicates or not.

Well, we could do both. So if you select an object (point, bone, etc.), you could see if it's a hold/reset duplicate by "selected" key color. But also have markers, to show if the whole frame is a hold/reset duplicate. Luckily, both keys and markers can be colored.

I'm just not sure how useful this would be in practice. I originally thought all you needed was to select an object to see if its key was a duplicate. But selecting multiple objects is always going to limit the usefulness.

What might be interesting is to transform a pair of identical keys into a hold. And have the opposite - IOW to take a hold key and make it no hold at start and add a key at the end (so that animation could be inserted)? not sure how that might work in a "multiple identical" situation though (e.g. as might be created by auto-freeze)

Easy enough to convert to a hold. Not as easy to convert to keys, after a change in between. It might be hard to "catch" the original hold duration, once you know a change is made. At least trying to do it automatically.