Proposal: Position control

I started to use FF recently and quite happy with results, especially Map node with Lua support. Really great!

But there is obvious thing that is missed: many filters use some kind of "X"/"Y" controls to define certain point on image (as a center of effect or similar). But this thing is really common this days and this is usually visualized as special dot on image itself (on preview), that you can just drag to the place you whant and script will get X/Y coords automatically.

So my suggestion is like this - add "Position" input control. It will be shown on image preview as a dot, that can be dragged around and script will get X/Y coords of the dot where needed. In case of several "Position" inputs - there should be several dots depicted (probably color-coded randomly or somehow)

Next level of coolness - if this "dot" can be scaled (size of dot can be adjusted on image preview) and rotated (dot can have 2D orientation) visually, And script will be able to get "size" of coresponding dot (via control node) and angle, if present

Ah yes, the good old Point control. This is something that has been on my mind for at least a decade, but, as Sphinx correctly points out, FF currently doesn't have a component and input type for Points. And even if we had one, we'd need a complete suite of math components to deal with the points themselves and their internal coordinates (floats). And this is complicated due to the fact that there's no polymorphism in Filter Forge -- that is, a component can only accept a single concrete type as inputs (e.g. green). With our current architecture, we cannot, for example, create an Add or Subtract component that can accept RGB colors, Points, Floats and other data types -- we'd have to duplicate them for each data type, so we'd end up with N versions of the Add component, each for a single concrete data type.

For the FF sequel, we're taking a principled approach to polymorphism. Our implementation is similar to parametric polymorphism in Haskell, complete with typeclasses. For example, if we have Int, Float, and RGB Color data types, and all these data types are members of the Numeric typeclass, you can plug them into any component that accepts Numeric, for example Add, Subtract, Multiply, etc.

That would work if our architecture had support for multi-out components. Alas, currently a component can only output a single value -- and that's why we need a data type in order to pack sub-values into a single value.

For the sequel, we're keeping the single-output restriction, but we will have support for arbitrary data types (not just three fixed types as in FF), and we will support tuples -- a record data type that lets you pack multiple values into a single value.