A node that can allow the creation of Keyframed value. Either one keyframe per node- or multiple (lets start with one).

Keyframes should allow the creation of bezier curves to allow smooth animation. It would also be good to allow the user a way of firing the animation- so that complex logic could be built into the composition and then trigger keyframes events.

Usage example 1:

Usage example 2:

Generated Layer Example (from QC):

QC equivalent: 



Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro


●●○○ — A few weeks of work


●○○ — Appeals to current community


@smokris, are there any new

alexmitchellmus's picture
Submitted by

Steve, are there any new thoughts on integrating gui Windows into Vuo nodes? How would you envision this sort of node working alongside other nodes? A user would need to be able to edit the curve via mouse interaction- and save key-frame data to file.

Also consider that a user may want to use such a keyframe view in an app. That isn't to say that the current tools for motion are not amazing, they are! However we could also drive other animation with key-framing, (just like scheduling- which is completely different again).

The output could be a layer, (or list of layers making a GUI interface). Inputs would be mouse position - and time. Also input and output of list key frame.

How would you envision this

jstrecker's picture
Submitted by

How would you envision this sort of node working alongside other nodes?

Not sure. What did you have in mind when you created this feature request? Beyond the obvious difference (UI in Vuo Editor vs. node), how would this feature request be different from Keyframe editor built in to Vuo Editor? Would the main advantage of this feature request be that it would be possible to use the keyframe editor in apps exported from compositions?

I think@jstrecker that this

alexmitchellmus's picture
Submitted by

I think Jaymie that this feature request would also allow a custom time input to be fed into it. Unlike how I envision key frame editing built into Vuo editor - in which there would only be key frame output values - not time input.

With a time input key framed values could be used to drive animations in a modular way (as opposed to one timeline you could have many interrelated timelines).

So this FR could be very powerful not only for key frame animation - but also for executing predefined animation routines.

What I would like to understand more is how team Vuo thinks this would best work? Would simply a layer output work (like in picture)? Or would there need to be a new UI view for nodes? Is that something that would be accepted as a Vuo FR?

Are you intending for the

jstrecker's picture
Submitted by

Are you intending for the keyframe editor ("Generated Layer Example") UI to be used by the person editing the composition or the person running the composition?

If for editing, the keyframe editor UI could be an input editor widget (similar to existing ones that you get when double-clicking an input port, though more complex than most).

If for running, the keyframe editor UI could be a widget in the composition (similar to the existing Make Button and the to-be-added User interface (UI) node set — buttons, sliders, text/number boxes, menus).

Neither would require implementing a new UI system, just building on top of the existing systems.

Yeah, I am thinking of both.

alexmitchellmus's picture
Submitted by

Yeah, I am thinking of both. Will look into input editor. However I didn't think that such a complex UI would work inside the editor.

Food for thought! Thanks Jaymie!

The one thing I am having issues with understanding is how a UI would work for a 'time control' UI. If it were implemented as an Input Editor then it would have no use unless the composition was running.

It would be very interesting to have a uniform way for users to make their 'own' interfaces for use within Vuo Editor. (not as a plug in or QT plugin) but created from within Vuo itself.

Here are examples of time controls in Adobe Premier which wouldn't make much sense without Vuo running:

Considering the voting system

jersmi's picture
Submitted by

Considering the voting system, I'm thinking I should have just cast my votes here instead of creating the "lerp" mapper FR. Could they possibly be combined, since anyone interested would likely be thrilled with either/or? That FR was in a way a response to the optimism at the time for a more complex, dreamy node like this. The lerp mapper was an attempt to propose something simpler.

Feature status

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for.

If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.

Read more about how Vuo feature requests work.


82 votes so far!

Who voted?

iaian7's picture
mixfilet's picture
zwei-p's picture
alexmitchellmus's picture
David's picture