20Concepts Lesson 02 - Vizzie Part 2

From Cycling '74 Wiki
Revision as of 03:21, 1 February 2013 by Darwin Grosse (Talk | contribs)

Jump to: navigation, search

(Needed: Example Video)

In lesson #1, we will extend the Vizzie system by creating switching networks, managing user interface and recording our work.


Switching Streams

Now that we are developing more complicated video systems, we may find that we only want some of the effects/videos active at any given time. We could repatch on the fly, but that would be more difficult than it has to be. What would be a better choice? It would be better if we could make multiple effects streams and switch between them.

We can accomplish this with modules found in the Vizzie CTL subfolder. Two useful devices are the 2SWITCHR and 2ROUTR. These are very similar devices: the 2SWITCHR takes two video inputs and switches them to one output; the 2ROUTR is the opposite, accepting one video input and sending it to one of two outputs. Either will allow us to create video streams and switch between them - so how do we decide which one to use?

This is where it helps to understand how Jitter (the technology behind Vizzie) works. The video patch cords pass a message every time a video frame changes. The modules are expected to do their processing, then send a message to the video modules connected to their outputs. Processing occurs (and CPU is used) every time a module receives a frame message - so it is helpful to limit the number of messages any module receives.

If we create this simple Vizzie patch:


we can see that all of the modules are connect to a PLAYR device, process frames, then we switch between the video streams with a 2SWITCHR. The problem is that the effects will receive frame messages even when their output is not being displayed! That's a lot of wasted CPU, and limits our ability to effectively use the Vizzie system. Replacing this arrangement with a 2ROUTR gives us a patch that looks like this:


Now, modules only get messages when they are switched in, and we are using CPU as efficiently as possible.

Centralized Control with User Interfaces

Turning Processes On and Off

Creating Video of the Output

Web Links