Control The ColorRamp Out Of The Group

Hello. I just test this weird "circular" method, and it works! (Blender 2.92) {attachment blender_0Jl1c8ACDVpng} {attachment blender_BbhuGhwPlYpng}

Thanks for bringing the topic et proposing a solution, a more flexible ColorRamp node would be very useful ! Two separate but related ColorRamp node features / evolutions seem to be regularly discussed :

1. ability to control each (color and position) through sockets, for easier control from outer values/nodes.
2. ability to set color ramp values from outside of a group

Your proposal would fix 1), and allow to work around 2) because it adds more flexibility, so it would already be very handy and your mockup illustrate well your proposal !

Following feedbacks on your proposal, I did a mockup adding a checkbox to toggle the sockets display, to keep it more similar to current implementation by default :

{attachment color-ramp-evolution-checkboxpng}

However, having a variable number of sockets doesn't feel like an optimal solution :

• it requires to "expose" in the group two values for each color ramp step which seems heavy
• adding a color ramp step for better control (either for inside or outside the group), would require to expose and rewire the new values (not very flexible)
• it brings questions regarding UI design and code / logic when sockets are added, removed, re-added, which don't have obvious answers..

For working with RGB colors and vectors, the "separate RGB/XYZ" and "combine RGB/XYZ" nodes are very useful : they allow to edit a single component, but also to transport the value through a single socket as "Image" or "Vector". Color ramps are more complex and can have variable number of steps, so I don't think their data can fit in current base socket types.

Animation / everything nodes seem to have list / array sockets, so it seems technically possible to create sockets that contain more complex types, or lists of variable length. This could help reduce wiring and rewiring for every additional color step, and keep the UI simple :

{attachment color-ramp-evolution-steps-socketpng}

Thinking further, maybe allowing "Node" sockets and exposing them as group inputs could be a generic and convenient solution.

The out-group node could act as a proxy and UI widget for the in-group node. The in-group node's values would still be overridable inside the group through sockets if needed, and keep it's own values if the group input socket is not connected.

It might not be useful for all nodes, but at least for those which have advanced UI widgets (ColorRamp, RGB Curves...) and could also allow to transmit values which are not directly exposed through a socket, or provide default values for full nodes.

{attachment color-ramp-evolution-node-socketspng}

It might help this topic's issue ("control the ColorRamp from outside the group" / point 2), but does not help for point 1 for which your proposal would be useful. Maybe everything nodes will provide ideas to create and manipulate Color Steps more programmatically through nodes.

It looks a bit too cluttered (too much information) but I like it in general

I am with this one too, with ColorRamp very complex textures can be achieved if the color stops were accessible.

I'm a fan of the concept, but I'm not fond of this particular solution.