Perhaps some in the VUO community would be interested in a recent exhibition driven by Vuo.
A couple of images attached, but basically a outside viewing dome, the projection is on the inside as part of a Mandurah (Western Australia) Performing Arts Centre event. Inside the dome are two bright projectors, two spherical mirrors, a laptop and a semi-random arrangement of tables, stacking blocks, cables, etc. The content is a series of fulldome (fisheye) video clips by a local artist David Carson and music by Justin Wiggan. The Vuo playback is quite simple, while there were variations it largely involves choosing a video clip, dicing it in half, warping it (calibration performed with another application) and sending to the two projectors (each a display on the laptop). Some other images attached showing projector arrangement, screens on laptop and Vuo screen dump.
Some comments during this process, but all in all Vuo served the purpose well.
Really liked (once I understood it, sorry for the posts earlier suggesting a problem) the way screens and windows are handled. So much better and more powerful than QuartzComposer where one needed Matrox boxes to do the same thing.
Life would have been much simpler if there was a event output from the movie player node when a movie comes to the end. I think this has been suggested by others.
I commented on this some years back. I do think Vuo is overloaded with redundant nodes, I found this slowed me down when looking for nodes I hadn’t used before … I would rather see less more powerful nodes than lots of variations. A simple example are all the maths nodes, there are so many of them, that are all unnecessary given the calculate node. There are lots of other examples of nodes that I feel could be combined or generalised more resulting in a simpler search and interface.
Discussions like this seem to only allow 4 file uploads. More I could share but can’t. :-)
Life would have been much simpler if there was a event output from the movie player node when a movie comes to the end. I think this has been suggested by others.
A simple example are all the maths nodes, there are so many of them, that are all unnecessary given the calculate node.
That’s a good point, and I’m trying (unsuccessfully at the moment) to remember if there was as specific motivation for doing it that way or if it was mainly because theCalculate node was not added until after the single-function math nodes. The Calculate node might be a tiny bit slower since it has to parse the mathematical expression, but I don’t think anyone has measured to see if the difference is ever perceptible.
There are lots of other examples of nodes that I feel could be combined or generalised more resulting in a simpler search and interface.
The ones I’m aware of are variations with different numbers of ports, like Select Latest (2) and Select Latest (8), which are planned be fixed with Select and OSC nodes with variable number of ports. Did you have other examples in mind?
Discussions like this seem to only allow 4 file uploads. More I could share but can’t. :-)
That’s odd, there’s no limit set. If you edit the post, can you add more files? If not, maybe we’d be able to figure out the problem if you could provide a screenshot, and in the meantime you’d be welcome to put more files in comments.
You say “The Calculate node might be a tiny bit slower since it has to parse the mathematical expression”. Surely the parsing only needs to happen once, in fact it must happen immediately because only then does it know what input ports to create.
Regarding the 4 file uploads, perhaps there was something else happening at the time, seems I can upload more now.
Regarding more generalised nodes … perhaps maths is the stand-out example. But I find myself often making sub compositions from multiple nodes in simply for generalisation. For example there is convert text to boolean, int, real, data. Why not one node with 4 outputs. I really doubt there is any measurable performance difference for the sorts of things people are using Vuo for.
Search for “convert point”, surely some of those can be compressed into multiple input or output nodes.
I guess this is “style” and “elegance” thing and not everyone will agree, but my vote is certainly for a smaller number of general nodes rather than a large number of specific ones. I also accept there is now a backwards compatibility issue.
You’re correct that the math expression is parsed once and then cached (in muParser’s bytecode form). So really the only overhead after that is interpreting the bytecode, and that’s probably not going to make a perceptible difference.
The main usefulness of the one-input, one-output Convert Blah to Blah nodes is as collapsible type-converters. For example, if you drag the output of Append Texts to an input of Calculate, a collapsed Convert Text to Real node is inserted automatically.
However, the type-converter nodes do take up a lot of space in the node library, disproportionate to how often you would actually go searching for one instead of letting it be inserted automatically. Some possible solutions to this problem lie in the area of improving node library organization. Right now there’s a flat list sorted basically (with some tweaks) by frequency of usage in example compositions. If you could view the nodes by category, hide nodes, personalize the sorting, etc., that would cut down on the clutter.
