Solving problems with event flow

Events are a powerful tool, as they make it possible for you to control exactly when each node in your composition executes. However, events fired at the wrong place or time can lead to problems. This section covers several problems you might encounter and the ways that Vuo can help you identify and fix them.

“Infinite feedback loop” error

One of the rules of events is that an event can travel through each cable at most once. This rule comes into play when your composition has a feedback loop.

As you learned earlier in this section, feedback loops are a useful construct for accumulating changes over time. You just need to regulate the flow of data through the loop. Here are examples of a working (regulated flow) and a non-working (unregulated flow) feedback loop:

In the working feedback loop:

• The event enters the Hold Value node’s Update input port and travels through to the output port.

• The event enters the Add node’s input port and travels through to the output port.

• The event hits the Hold Value node’s Value input port and is blocked by the event wall.

In the non-working feedback loop, there’s no wall to block the event from looping through the Add node over and over. Vuo reports an infinite feedback loop and doesn’t allow the composition to run.

Comparing the two compositions above, you can see that one way to fix an infinite feedback loop is to insert a node with an event wall, such as Hold Value.

Another way to fix an infinite feedback loop is to get rid of the feedback loop. In the composition above, you could replace the feedback loop with a Count node. The Enqueue node and the Blend Image with Feedback node can also take the place of some feedback loops.

Rarely, you might encounter situations where Vuo reports an infinite feedback loop even though you can logically reason that the loop is finite — like in this composition:

The event would only circle the loop 10 times, so it’s not infinite. Nevertheless, you’ll need to restructure your composition to avoid the error. When iterating through a fixed number of items, you can use a Build List, Process List, or Spin Off Events node. (Alternatively, you can circumvent the error by inserting a Spin Off Event node in the loop, but be aware that you could create an actual infinite feedback loop that causes your composition to freeze.)

In most cases, an event needs to travel through all of the cables leading up to a node before it can reach the node itself. (The one exception is the node that starts and ends a feedback loop, since it has some cables leading into the feedback loop and some coming back around the loop.) A problem can arise if the nodes and cables in a composition are connected in a way that makes it impossible for an event to travel through all the cables leading up to a node before reaching the node itself. This problem is called a deadlocked feedback loop. If your composition has one, Vuo will tell you so and won’t allow your composition to run.

This composition is an example of a deadlocked feedback loop. Because the top Hold Value node could receive an event from the Fire on Start node through the cable from the bottom Hold Value node, the top Hold Value node needs to execute after the bottom one. But because the bottom Hold Value node could receive an event from the Fire on Start node through the cable from the top Hold Value node, the bottom Hold Value node needs to execute after the top one. Since each Hold Value node needs to execute after the other one, it’s impossible for an event to travel through the composition. To fix a deadlocked feedback loop, you need to remove some of the nodes or cables involved.

Buildup of events

What if a trigger port is firing events faster than the downstream nodes can process them? Will the events get queued up and wait until the downstream nodes are ready (causing the composition to lag), or will the composition skip some events so that it can keep up? That depends on the trigger port’s event throttling setting.

Each trigger port has two options for event throttling: enqueue events or drop events. If enqueuing events, the trigger port will keep firing events regardless of whether the downstream nodes can keep up. If dropping events, the trigger port won’t fire an event if the event would have to wait for the downstream nodes to finish processing a previous event (from this or another trigger port).

Each of these options is useful in different situations. For example, suppose you have a composition in which a Play Movie node fires events with image data and then applies a series of image filters. If you want the composition to display the resulting images in real-time, then you’d probably want the Play Movie node’s trigger port to drop events to ensure that the movie plays at its original speed. On the other hand, if you’re using the composition to apply a video post-processing effect and save the resulting images to file, then you’d probably want the trigger port to enqueue events.

When you add a node to a composition, each of its trigger ports may default to either enqueuing or dropping events. For example, the Play Movie node’s trigger port defaults to dropping events, while each of the Receive Mouse Clicks node’s trigger ports defaults to enqueuing events.

You can right-click on a trigger port and go to the Set Event Throttling menu to view or change whether the port enqueues or drops events.