Status: 

Vuo version: 

Fixed in Vuo version: 

Steps causing the bug to occur: 

  1. Load BlendImages.vuo example
  2. Wonder why vuo.time.firePeriodically is used, when the event model of vuo can mean render updates need happen when there's something to do.
  3. Also magic numbers are bad. It isn't obvious that that number is 60fps, and even if it were, it's bad design to assume I'm rendering at 60fps.

How did the result differ from what you expected?: 

That's not what you'd expect to see, if you've just read the manual and thought 'all right, this event/evaluation model is quite powerful'.

Comments

This is just a guess, but I

mnstri's picture
Submitted by

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

smokris's picture
Submitted by

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.

@smokris Great. Thought it

tobyspark's picture
Submitted by

Steve Great. Thought it all a bit odd.

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

smokris's picture
Submitted by

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.