As one of Vuo's developers, I work on Vuo's engine (the thing that makes compositions run), work on nodes, and write documentation. You'll see me on the forums answering people's questions about Vuo.
I enjoy using Vuo to make live music visuals. My hope for Vuo is that it will grow into a community of people of diverse backgrounds and identities making lots of different artistic, useful, unique, goofy, beautiful, crafty, wonderful compositions.
Estoy practicando para ser competente en español. Si publicas en el foro en español, trataré de responder en la misma manera.
@marioepsley, unfortunately no, Oculus Go is different enough that it wouldn't be covered by this feature. Because Oculus Rift attaches to a computer and shows up as an external display, supporting it is just a matter of implementing the I/O. Oculus Go is an Android-based mobile device, so it would require the ability to run compositions on Android (feature request) in addition to the I/O.
Maybe a little background on how the composition starts and stops will help…
When a composition starts, first nodeInstanceInit() is called for each stateful node. Then, nodeInstanceTriggerStart() is called for each stateful node that implements it.
Both of these functions are involved in initializing / setting up the node. nodeInstanceInit() is responsible for creating the node's instance data. nodeInstanceTriggerStart() is responsible for starting any background threads that can potentially fire a trigger.
The reason that the initialization is split into two phases — why you can't just do it all in nodeInstanceInit — is that all nodes need to have their instance data ready before any nodes start firing triggers. Otherwise a trigger might fire an event into a node that hasn't been set up yet.
When the composition stops, the two phases happen in reverse. First, nodeInstanceTriggerStop() is called for each stateful node that has it, and the composition waits for all the triggers to stop and all events in progress to trickle through the composition. Then, nodeInstanceFini() is called for each stateful node.
Now, nodeInstanceTriggerUpdate()… This is called when you edit an input port value on a node while the composition is running. For example, if you have a Fire Periodically node and you double-click on Seconds and change it from 1 to 2, that prompts a call to the Fire Periodically node's nodeInstanceTriggerUpdate().
Actually, walking through all the steps with Fire Periodically might be instructive…
So you have a composition with a Fire Periodically node in it, with Seconds set to 1. When you start the composition, first the nodeInstanceInit() function is called and then the nodeInstanceTriggerStart() function is called. nodeInstanceTriggerStart() starts a timer that runs in the background. Every 1 second, the timer goes off and the Fired trigger port fires an event.
When you double-click on the Seconds port and change it from 1 to 2, the nodeInstanceTriggerUpdate() function is called. This function cancels the 1-second timer and starts a 2-second timer. So now the Fired trigger fires every 2 seconds.
When you stop the composition, nodeInstanceTriggerStop() is called. It cancels the 2-second timer (and waits for it to really stop). Finally, nodeInstanceFini() is called.
Does that make sense? Looking back at the source code of nodes that use the isTriggerStopped variable/pattern, do you now understand it?
OK, good to know. We'll have to do some research before we can open this for voting. Not sure how a macOS application is supposed to capture per-application audio these days. It used to be that you implemented a HAL driver, but that seems to no longer be supported. If you happen to find any info about this (or decide you want to take it on yourself), please let me know. I imagine the structure of the code for this would look something like the vuo.audio.receive node class, VuoAudio library, and other related libraries.
simple question, i hope: what does that sign means, what does it do and how to handle it? The gray sign left and right of the Window-port.
That's a hidden cable. You can right-click on the port and select Unhide Cable, or shift-cmd-H (View > Show Hidden Cables) to unhide it temporarily. If there's a long cable stretching across the composition and it's a commonplace connection (like Showed Window output port to Window input port), I like to hide the cable for neatness, so it's easier to see the interesting cables.