Ability to type expressions directly into value fields

[WolfInABowl]

Is your feature request related to a problem? Please describe

When animating FX, there are many situations where you wish to use a simple expression to drive the value of a parameter. An example would be using the expression f to change the value linearly over time based on the current frame's number.

To write an expression, you need to go to the Function Editor, locate the desired parameter, set the Interpolation Mode to Expression and finally enter the expression (making sure to hit Apply). This feels a bit cumbersome when the expression itself is very simple, as the aforementioned steps contribute the majority of the time taken.

Describe the solution you'd like

Inspired by Blender, I think a user-friendly solution would be to allow directly entering expressions into value fields using a prefix such as #. This would then automatically create the expression when the user presses enter.

Currently, if a value field is driven by an expression and the user tries to modify its value outside of the Function Editor, the change will simply be rejected. With the above change, it would be useful to instead display the expression when the user attempts to edit the value in the field, allowing them to alter the expression without needing to return to the Function Editor.

Example:

[RodneyBaker]

In my experience the trigger character for expressions is usually an equal sign (=). This is fairly traditional for spreadsheet program expressions from programs like Excel etc. Example: "=valuex"

I definitely like the idea of adding expressions more easily in places where appropriate.
For instance, I'd love to be able to enter an expression directly into xsheet cells.
Imagine you want a column/level to align with the camera but to advance in a direction by the value of the current frame.
We'd enter something to the effect of "=camera.x+frame" or "=cam.x+f*2".

Here's an example from the every ubiquitous spreadsheet program Excel:

I would imagine that the logic for storing values (whether they be actual values or expressions) would need to be added to the code because they likely are only used as a temporary holding place until the enter key is pressed in which time the value is input into the underylying database. I don't think we currently have a 'live' connection although perhaps in places we do... I'm thinking brush sizes and such.

I do see the hash mark (#) as being useful and it currently is used in Opentoonz for drilling down to objects/layers in PSD files. That can be seen by opening a PSD file in OT and checking the path via Level Settings. There the path appears to be simply stored as a pointer... again no 'live' connection but when prompted for a refresh it surely uses that path to find the source and provide the update.

In this sense a 'path' entered as an expression would not only resolve the location but also any relationships via math.

Bigger picture thoughts
There are a number of locations where it would be most useful to leverage expressions and most of those fall outside of the scope of this request. For instance, expressions might be a way to bridge the gap between palette styles and column channels.
I suppose the idea here would be to identify prime locations for updating the fields to allow for expressions.
In the process of updating those however it would be good to consider how expressions themselves might evolve in the future.
For instance, entries of Regular Expressions.

That of course would be handled by the process that validates expressions so the primary addition here is that trigger symbol that would signify the data thereafter is to be parsed/registered as an expression.

There is also the matter of prompting the user for input when they enter the trigger symbol... or as Opentoonz already does when adding an expression give hints based on what the user has entered thus far. Here is a random example from another program:

At any rate, I like the idea.
It's mostly a matter of how best to press forward and get that functionality implemented.

[gab3d]

I like the idea.
To be honest, the equal sign is to me the most discoverable one for entering an expression.

Another expressions related feature that would be great to have, would be that expressions be by default additive to the keyframes entered for that channel.
That'd give the user a very straighforward way of art-directing the result of an expression in a certain channel. Currently to be able to do something similar, the user would need to create a parent object (but that only applies to transformation channels, in other type of channels there's no clear path to obtain such a possibility).

[Bracket-H]

That would be helpful, but what I would like even more would be temporary variable support, so you can use the current value of a columns attribute, save it into a temp variable (even if it's just one or two ...) and then operate on that value before putting it back into the attribute.

You can't do something like (pseudocode): column1.X = column1.X + 5
Because that's a circular dependency error. Why? I don't know. OT Must be evaluating this in a weird way...and it denies basic things like the above and similar stuff, and it makes things like creating animation rigs/controllers harder, too.

For example: Creating a controller like this for 2D Cutouts and other 'boney' stuff is a huge pain as it is now.
Edit: Obviously 2d dolls aren't this powerful...but the focus is the 'controllers', the handles and splines you can grab to change expressions and stuff
https://www.youtube.com/watch?v=ueYtM2KprqY

This can be done with columns that act as controls, but it's difficult to clamp them to a value, for example.

let's say you draw a level that represents a knob on a slider, not to be rendered in the final compositon, but as a tool to work with.
And you place it onto your scene as a controller for something that works on a doll part column.

And you place this knob on the X coordiate of 0, and you want to interpret this as '0'
And the maximum travel on the X coordinate should be 200 pixels to the right, which you interpret as 1

So if you drag this knob to the X coordinate of 200, the doll part would receive a '1' for its controller input.

Thing is, you can't clamp it, you can't limit it to 200 easily because if you were to go (pseudocode)
If (knob.X > 200) knob.X = 200

Then you can't you do that!
Because it's a circular reference.
So you have to do awkward workarounds, when in reality this is a super simple thing that any program should be able to do.

[gab3d]

@Bracket-H

You can't do something like (pseudocode): column1.X = column1.X + 5
Because that's a circular dependency error. Why? I don't know. OT Must be evaluating this in a weird way...

That's because a channel's value can either be defined by a key xor an expression. i.e. the expression completely replaces the key as a form of assigning value to the channel.
In other words, the "current value" of a channel (the one defined by keys) ceases to exist, the very moment you set-up an expression.

That's another advantage of the "layered" expressions system I refered to above.
As it'd exist "above" the key values, it could reference those values to operate on them.

[shun-iwasawa]

@Bracket-H

You can't do something like (pseudocode): column1.X = column1.X + 5

Please try cycle(1)+5 to obtain the arithmetic progression.