Node Input Schemes

[RobertGlobant20]

Dynamo version

1.2.1

Operating system

Windows 7

What did you do?

See below.

What did you expect to see?

See below.

What did you see instead?

I didn't know where else to put this, so here it is:  Blanket statement:  All below suggestions assume performance speed is not greatly reduced by implementation.  Some suggestions could be implemented via an optional UI switch.  List@Level - Adjusts area of list focus PRIOR to entering nodes.  It’s awesome even if its dependency upon Top-down list hierarchy slows performance (compared to GH) a bit.  It cannot be expected to solve node behavior once data enters into the node.  It effectively replaces GH nodes like Shift list among others.  It effectively reduces dependency on DS nodes such as list.chop, list.flatten and some others whilst allowing the user to retain more of the list structure as needed, and with much fewer nodes.  Var, var[], and var[]..[]  -  These are useful for designing a custom node (or a built-in node).  Var looks only for a single item, var[] looks for a list.  But we should make it clear that var[]..[] is only used when upgrading a workflow that was initially built to handle a simple list—ie a LOFT Node built to create a SINGLE loft would be looking for 1 (maybe 2) inputs-- a single list of curves and perhaps 1 or 2 guide curves.  Assigning these expected formats to inputs should only be done in the workflow of converting a singular workflow to a workflow that handles a multiple of that condition.  A best practice, and maybe a useful restriction to this workflow, would be to “Only ever increase expected input list depth by one level when creating a Custom Node from a singular workflow”.  Here is a suggestion that may not be popular among automation enthusiasts, but with regard to Lacing and List.Combine, we may be looking for a shortcut (in the short term) that simply doesn’t exist.  The amount of use cases for geometry creation and data management is so vast that expecting to know them all up front may be unrealistic.  As Brian R. says: “Doing the same thing manually more than once IS Insanity”, BUT doing the same thing slightly differently more than once is WORK, and sometimes it can’t be avoided.  Read below to get the meaning:  During the growth of GH into a fluid tool—there was much back-and-forth about how to handle DEFAULT behavior for certain nodes (Dyn Team has/is undergoing similar discussions), especially simpler nodes such as line by points.  For example:  “What happens if input ‘A’ passes a list and ‘B’ passes a single object?!?”  This is the core of the frustration of a “Node with Inputs” type format.  Once the data enters the Node, IT’S IN.  Simpler nodes with fewer inputs can have a logical default behavior that most users would expect—but limiting, say, line creation to a specific expected input is LIMITING.  There are 2 obvious solutions:  1.   Create multiple nodes, one for each case--  This has happened to some extent already— ie. Geometry.Interesect and Geometry.IntersectALL etc.  2.    Create multiple possible schemes and embed them within a single node.  I agree with Andrew H.-- I create Custom Nodes to work with a single item workflow first, then wrap it in a Custom Node and pass multiples in.  I’ve created custom nodes with many inputs (>3) to work for a workflow specific to MY graph.  Most inputs expected a single variable—integer, double, string etc, and only 1 or 2 inputs expected a LIST.  This kept the node within the realm of solutions like Lacing and List.Combine.  But I have occasionally wanted to CONVERT additional inputs from expecting single items to expecting LISTS, but without losing my original configuration.  ENTER INPUT SCHEMES.  As additional use cases arise, additional custom node graphs can be created—using the same process as before, build for one workflow in the main canvas first and then wrap it inside the custom node to pass data with 1 level of increased depth. The difference is that MULTIPLE WORKFLOWS could be embedded in the SAME NODE.  This solution is similar to what Ant-B-Thorp was saying about a machine predicting what lacing a user wants (Machine learning could easily be inserted into this workflow later) but it is a little simpler and harnesses the inevitable growth in user contribution at all levels.  The Now Solution requires a mechanism to switch between schemes and an upgrade to the UI. UI - Inputs could have different color values (or lightness/darkness of grey for the color blind) to indicate if the active scheme expects a SINGLE VALUE (light orange?) or a LIST (deep orange).  The left inputs edge could be click-expanded to reveal input schemes for selection.  Alternatively, the user could click on a single input to change it from SINGLE to LIST or LIST to LISTofLISTS.  A little work here could automate scheme-change upon clicking a single input based on what/how many schemes are under the hood.  ADDITIONAL THOUGHTS Input Schemes are Scalable even if industrial for the majority of cases.  It helps eliminate many of the solutions (Lacing, List.Combine) which promised to be something much more but were really just solutions for specific cases.  Custom Nodes should have the same automated integration of List@Level as built-in nodes.  List@Level, if it doesn’t hamper future upgrades or greatly restrict performance/speed, should be committed to here.  It is critical to think about software as a closed system when it comes to speed.  Everything we add may slow performance down, so with every additive change it is important to ask “What can we remove”.  Cloud computing will make many things possible that were not possible when GH was being developed, and Dynamo should take advantage of this by allowing more sophistication/complexity into its engine by Embracing input schemes in native nodes as well as allowing users to build their own input schemes.  GH also had to get over the hump of making scripting cool—David R. and McNeel kept many of the decisions about node behavior locked down (while listening to forum suggestions).  But coding and its frame of mind are more mainstream now and will continue to grow.  Dynamo should anticipate this and continue to embrace whatever intermediate levels of fluency emerge and are required to propel sophistication forward.  The UI should not be ignored however.  Design is a very visual endeavor, and keeping both sides of the brain engaged throughout the process will yield better results.  Node inputs should also be visually distinct if they carry a default value.  I think this concept takes many users by surprise.  Replication guides, unless they are much faster than other methods, seem redundant to List@Level and INPUT SCHEMES.  My hunch is these could now go away or be buried a little more to not confuse newer users as they are DS only.  Also agree with (I can’t remember who) that Custom Nodes should be allowed to reside inside a Graph.dyn without being saved as an outside custom node.  Saving in same local folder is a good workaround, and creating packages has its benefits, but sometimes a one-off node really doesn’t want it to be separated from the mothership.  At first I thought this limitation was on purpose to promote code sharing, but the need is there.  Maybe this will go somewhere (or show us one way not to do it). Best Regards.

[github-actions[bot]]

FYI: @RobertGlobant20/issues_action