Signature changing properties (Mode select enums)

[ly29]

Unlike simple properties that do not change the node signature but can be supplied with a simple keyword argument some nodes should be able to change the signature based on a mode enumeration for or an other property. These properties are not controllable in a simple way via the external configuration dict since the change of signature affects the compilation stage.

Consider for example a simple trigonometry nodes supporting say sin, cos and tan. All simple f(x: float) -> y: float functions.

In this case type could of function could simply be supplied as keyword argument, however if we add the atan2 function we need two arguments.

This can be handled in number of different ways non which feels totally optimal right now.

1. Create different nodes math function we different number of arguments and types. This I consider non optimal because the added complexity of finding the right function in the user interface.
2. Include a `def compile(self): returning the relevant function signature based on the current value of the ui nodes. This somewhat breaks the current abstraction boundaries and probably should be placed in later stage of the process.
3. A node corresponding to each function signature where changing the mode enums switches the node in user interface to the node corresponding to the new signature. This is conceptually simple and works well with the abstractions in place but generates, potentially, a very large number of nodes.
4. Behave like cycles and have all math function have two inputs even if one of them is mute.

1 and 4 I don't like, 3 has a lot of simplicity going for it but 2 is probably the right option but exactly how it should be implemented I am not clear with now.

[zeffii]

I like 4, even though it's not elegant -- but perhaps with input an output hiding (which doesn't change the socket indices) it isn't a totally bad idea. Certainly there would be less gymnastics.

• 3. hot swapping a node is also fine, the user would pick a math node, it might start out as an Addition math node, and if the user modifies the mode then it is replaced with a different dedicated node. Each node would have the ability to change itself to another kind (from the enum). I don't worry so much about having a node for each math function (most of it will be behind the scenes anyway -- seen as we can have a procedural generation of inherited nodes).

I don't understand what you mean with 2. and perhaps 1 and 3 are the same process but looked at from a different angle?

[ly29]

Regard 1 it is to not allow signature change basically, but force a ui node that corresponds two a series of signatures. Simple to implement but non functional from a ui perspective.

For 3 Something like this, you add a math node, the default being Add, which is represented by SvRxAddNode, changing to Sine change the node to SvRxSineNode which has a different signature, while reconnecting links as needed.

So 1 and 3 are different, but both keeps a consistent interface for the later stages, the complexity is only in the user interface.

2 and 4 move the complexity to the compile side, exactly where it would happen is a good question. For this I think implementing properties in #17 and cleaning up the compile code will give a good idea about which way is the sanest.

[nortikin]

3 will looks like current implementation, but behave some different. i like it