VL : Execution order

vl

#1

Hey all!

Is there a common routine for forcing execution order of nodes within patches?

Routines I’ve found so far:

  • Node then Node : Put early code into an If region which is set to True and pass the inputs to the later function through the If region (e.g. with an IOBox in the middle). I think this was joreg’s method.
  • Node then Node : Use IsAssigned node to take any output of an earlier node and feed it into the Apply of a later node
  • Loop region then Node : Pass something through the accumulator argument which becomes the input for the Node

These types of approaches presume that out earlier nodes have outputs and that our later nodes have inputs (can be forced with Apply), and we can somehow make a route between the two. I’m a fan of the graph defining the chronology of events, but we might want to be able to have a language-specific feature particualrly for this purpose (perhaps there already is one?), e.g.:

  • Expose a special ‘execution order’ pin (perhaps in the IOBox style input/output combined pin to visualise the flow of execution)
  • Some kind of layer assignment with priorities (blerggh)

Also I think the editor can be aware of where there are and aren’t ambiguities about execution order in the patch, so any extra interface could be limited to those cases. Also I presume any feature relating to this would be optional via Configure


#2

i always go for the if-region approach. can also be forced with a dummy bool variable passing through all the regions, if there’s no instance available to pass around


#3

Thanks!
I remember joreg mentioning the if hack before.
I presume that once other patching issues arise then a clever workaround will come.


#4

i think the if hack is not so bad in the end. wouldn’t be surprised if that construct gets optimized by the compiler anyway, so that it might just be a ui/readability ‘problem’… maybe we just want to have some kind of order-region which basically is an if region that’s always enabled and the pin is hidden.


#5

yes i presume that it is basically ‘free’ - but it’s certainly backwards thinking.
My instinct is that the solution should be more about Nodes than Regions


#6

indeed the if-workaround is just a workaround. we’ve been thinking of an explicit language-feature that would allow you to define execution order for edge-cases. only priority of it is not too high for it atm since the if-workaround is working ok for the rather rare cases we stumble upon it. anyway, absolutely on the list.


#7

How about selecting the link setting the order. Users can read that the pathway will be triggered first.

Give the link a label and/or a decoration to demostrate its order on the canvas. And the lower order of the other links, ofc.