I may have the dumbest question ever submitted here but is there a special background reason why I can’t refresh the main Fire Port of the Fire On Start Node ?
Could/Should there be a Reset Port added to it ?
It would be handy when Livecoding to be able to connect a Fire Periodically port to the Fire On Start node and disconnect it when done live coding.
I realize this will be less important with the new feature request “Auto Refresh Node when value changed” to be implemented.
My actual workaround is to connect both the fire nodes to a share value node but still I was wondering … Does the node really interacts when the composition starts ?
Not a dumb question at all. The refresh port on the Fire on Start node (and other nodes with only trigger outputs) is a usability pitfall, because it doesn’t do anything. We (Team Vuo) have actually been discussing getting rid of the refresh port altogether, since (a) it doesn’t do anything for some nodes and (b) it doesn’t do anything essential for other nodes (with a few exceptions, e.g. Hold Value, that we would redesign).
Your workaround — connecting both the Fire on Start and the Fire Periodically node to a Share Value — would be the best way to solve your problem right now.
So @jstrecker we would then have a make object, or build object or similar port for 3D Objects- if there were no refresh port? So looks like big re-design (at least on surface) will happen in future! :-)
However if the refresh port is taken away, there will still be the issue of wanting to fire the fire on start multiple times anyway, in which case possibly a manual fire could be added anyway? Change name to Fire on Start or Fire?
we would then have a make object, or build object or similar port for 3D Objects- if there were no refresh port?
On those nodes, an event into the refresh port doesn’t do anything different than an event into any other port (no walls, doors, or port actions). So instead of feeding a cable into the refresh port…
… you’d feed an event-only cable into any other port…
However if the refresh port is taken away, there will still be the issue of wanting to fire the fire on start multiple times anyway, in which case possibly a manual fire could be added anyway?
As @Bodysoulspirit pointed out, wouldn’t that be pretty well handled by Fire an event from Node when an input value is changed in the Editor?
(See also the Spin Off Event node.)
@jstrecker wouldn’t feeding an event into the transform of a make scene node be super confusing for new users? At least now there is a big arrow triangle (that’s a bit like a play button).
Having taught Vuo (and teaching) this may not be so intuitive for new users… But that is my opinion.
I understand this technique is used throughout Vuo but for such an important node function (as initiate) seems unintuitive. (Hence the whole conversation on event triggers)
@alexmitchellmus yeah my first thought too !
After some reflexion I’m wondering.
What is easier ?
A - Have Refresh Ports + Value Ports, tell new users you can OR connect here, OR connect there, that the results won’t react the same here or there.
B - Have Input ports only and tell people that the first node of a chain needs a fire to launch the chain, but that for all downstream patches the flow flows ;)
Can’t decide what’s easier ;)
@jstrecker wouldn’t feeding an event into the transform of a make scene node be super confusing for new users? At least now there is a big arrow triangle (that’s a bit like a play button).
@alexmitchellmus, I’m not sure yet. We’d have to test it to really know.
Part of our motivation for wanting to test it is from my co-worker’s experience teaching Vuo to someone. He gravitated toward the refresh ports because they are big arrow triangles, but he did so even when the refresh port wasn’t the right choice. If someone is trying to feed a data-and-event cable into a node, then they don’t want to be dropping it onto the refresh port and losing the data. And if someone is trying to use an event input port such as the Play Movie node’s Play port, again they don’t want to be dropping a cable onto the refresh port. This is just one person’s experience of course. We’d need to test to see if taking away the refresh port would make things less or more intuitive.
Personally I would go with what is the “right choice” and then make it simpler from then on. Especially if it makes Vuo more logical!
