Key animation tab/window rewrite

[synfig]

Key animation tab/window rewrite

[caryoscelus]

I don't see how merging parameters would help anything. It will only make interface less flexible and maybe just a bit more fancy. Somewhat tighter integration (e.g. #246) would be good, but not critical.

As for graphs - yeah, it might be a good idea to merge them. But it might turn out to be too complex for little benefit.

I think that better waypoint editing should have the most priority of what you mentioned, because it affects productivity the most.

Anyway, at some point when/if i finish multiple timelines i will be forced to dig some timetrack ui code. I'll see what can be done then.

I think we are totally on the same page.
The keyframe column in the parameters tab seems to be 100% redundant
Having Graphs and keyframes in one window like Blender or AfterEffects is a big part of making Key editing more intuitive;

So, is there anything in the works - any particular ideas or takes on that whole issue?
I admit that my interest in synfig is more general motion graphics than character animation, but it seems like the need for proper keyframe control is universal.

[caryoscelus]

Hmm, i never actually noticed the "time track" column in parameters dock - it happened to be always hidden by scroll. Cutting that out should be really simple, though maybe that should be optional if someone needs it.

You seem to refer to what synfig calls "waypoints" as keys/keyframes, but synfig has another concept called keyframes. (http://wiki.synfig.org/Keyframe#Keyframes_and_waypoints)

I'm not doing any big gui-related work at the moment and i'm not sure i will ever get to it in foreseeable future - there's so much to do in the core and i'm also not very good with coding guis. However i'm doing time-related coding now, so when i'm done with that i'll have to tackle time track somewhat and at that point i might consider improving it generally.

Actually i have an idea to replace current waypoint interpolation system with more fine-tuned one based on curves (similar to your first screenshot) and that would surely need the ui for it to be usable. But it's more "it would be nice to have it" kinda of an idea, not something i have a specific a plan to work on.

As for the others - i can't say anything definite, but commit history and pull requests hanging in the tracker kinda speaks for themselves.

[caryoscelus]

More on timetrack in parameters dock: it can actually be easily disabled either at compile- or at runtime.

// comment this out if you don't want the params dialog to have a 'timetrack' column
// (alternatively, export SYNFIG_DISABLE_PARAMS_PANEL_TIMETRACK=1 in environment at runtime)
#define TIMETRACK_IN_PARAMS_PANEL

So i guess the right thing to do would be to change the default to disable and see if anyone complains ^_^

I didn't know about Keyframes vs. Waypoints. What are Keyframes used for?
If I understand both correctly I'm confused by the naming convention:

"Keyframes" build the interpolated way between defined values.
"Waypoints" describe the key values that get defined.

Anyway - I'm not sure what you have in mind with that new interpolation system, but it would be awesome to be able to control TCB parameters just like you can control splines. (maybe even render them the same way under the hood?)

[caryoscelus]

I think that was answered a ton of times, but anyway. In short, keyframes are used to automatically create waypoints when you create waypoints "near" (but not on) keyframe and to scale waypoint positions (if you have two kf and wp between them and move one of kf, wp will move accordingly to keep relative position between kfs). And i don't see how keyframes can be described as "build the way"..

As for interpolation - that's pretty much what i meant. It's just that i don't know how they work atm exactly and thus said "new system". Maybe it will only require editing current system.

And yeah, i hope it'll be possible to reuse rendering & editing code from regular curves to parameter-controlling curves.

This is connected to #265 where I think the actual discussion needs to happen first.