This is just a guess, but I think it’s there so that you can manually change the blend mode and slide the opacity slider and actually see the effect.
But I personally think that manually editing the input ports – i.e. using sliders, selecting things from a list, typing a number and hitting enter – should also trigger events and execute the node. So the Fire Periodically wouldn’t be needed there.
@tobyspark: Yeah, the magic number is a temporary workaround. The Render Scene to Window node has an output port called requestedFrame which is driven by a CVDisplayLink (so it will automatically fire in sync with the actual video refresh). The Render Image to Window node doesn’t yet have that port, but it will soon (planned for Vuo 0.5.3); at that point we’ll update the composition to reflect that.
@mnstri: Yes, as of Vuo 0.5.1, when you change a constant value in Vuo Editor, no event is fired — so, in order to see your changes, the BlendImages example composition renders continuously. Team Vuo is discussing a few options for improving the way live-coding works, to make it easier to see results when making changes to the composition, without having to continuously evaluate like this.
My suggestion for firing updates ties in with talk of QC’s input splitter type nodes. I’d suggest if you insert an input splitter rather than use the collapsed (is the term? it’s all new =] ) value entry then changes would fire updates.
The Render Image to Window node doesn’t yet have a requestedFrame port, but it will soon (planned for Vuo 0.5.3); at that point we’ll update the composition to reflect that.
Actually we managed to fit that into Vuo 0.5.2 (now available), along with a new Fire on Display Refresh node.
https://community.vuo.org/t/-/4549 is in part a proposal for handling the other issue here: live coding / signifying when to fire on updating input values