It’s very necessary for making comps that are deployed as stand alone apps or used inside other apps (like FCP X and Motion for example) to be able to programmatically change the state of input ports and even to hide them in some contexts. Sometimes the host applications handle some of that but they can never be expected to handle all of it. In the case of FCP it was always necessary to wrap QC composition in ObjC code to have dynamic UIs within FCP/Motion
An example is enumerated list for composition background. Options presented to the user are no fill, solid fill, gradient fill, image, live image from internet…
Depending on the users selection of menu item, other inputs become visible e.g. for solid colour a standard colour picker input is shown, for ‘gradient fill’ a range of colour pickers and position sliders are shown (or a custom UI object), for image a list of preset images is loaded into a list to be selected from, etc etc. So in this case it would simply be a case of hiding and exposing certain ports given the context of value in the governing enumated list.
Another example is changing the minimum and maximum values on a slider range, and changing the step value (for up and down arrows) on input sliders. I often have situations where these need to be set dynamically but it’s not possible in Vuo (And was never possible in QC which I have vastly more experience with, other than writing code outside the QC Editor).
Often the interval value on Vuo value inputs is irrelevant to the required step size to make a meaningful change in the composition.
Another example would be a node that is a Text Editor with a simple GUI. One port could be a choice of setting it from ASCII/Unicode/.txt/rich-tect etc text formats. The text input would be limited to the chosen format and convert it’s prior contents to that format if the format was changed.
I figure because this flexibility would add baggage to any node where it was implemented, a new Dynamic Shared Value node should be created, rather than burden all other nodes with more boilerplate and unnecessary complexity. Values would then be passed from the Dynamic Shared Value node would be passed to where it needs to go, including any state logic that results from user input changes (i.e. list item selections, checkbox selections).
Does this make sense or do I need to clarify? I avoided exmples from QC, building QC apps using Kineme’s former App Builder and host applications like mimoLive, (formerly) PresenterPro but that’s more my range of experience dealing with these limitations and what a show stopper static port creation can be.