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):
Iâve opened this feature request for community voting.
@smokris, 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 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 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 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. Will look into input editor. However I didnât think that such a complex UI would work inside the editor.
Food for thought! Thanks @jstrecker!
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, 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. Â
Actually, your lerp mapper FR has a greater chance of being implemented in the forseeable future since itâs more focused and somewhat less complex. If anyone would like to move votes from this feature request to that one, let us know. Although thereâs some overlap, weâll keep this feature request open to cover the BĂ©zier curves mentioned in the proposal.
