20Concepts Lesson 02 - Vizzie Part 2 - Revision history

Corymetcalf at 21:36, 8 May 2013

2013-05-08T21:36:28Z

Corymetcalf at 21:35, 8 May 2013

2013-05-08T21:35:05Z

Ddg@cycling74.com at 15:53, 30 March 2013

2013-03-30T15:53:08Z

Ddg@cycling74.com at 07:50, 30 March 2013

2013-03-30T07:50:23Z

Ddg@cycling74.com: /* Centralized Control with User Interfaces */

2013-03-30T07:38:44Z

‎Centralized Control with User Interfaces

Ddg@cycling74.com: /* Turning Processes On and Off */

2013-03-27T22:06:36Z

‎Turning Processes On and Off

Ddg@cycling74.com at 02:53, 7 February 2013

2013-02-07T02:53:50Z

Ddg@cycling74.com at 16:40, 5 February 2013

2013-02-05T16:40:59Z

Ddg@cycling74.com at 03:21, 1 February 2013

2013-02-01T03:21:39Z

Ddg@cycling74.com at 19:57, 29 January 2013

2013-01-29T19:57:12Z

← Older revision		Revision as of 21:36, 8 May 2013
Line 8:		Line 8:
	(Needed: Example Video)		(Needed: Example Video)

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

← Older revision		Revision as of 21:35, 8 May 2013
Line 1:		Line 1:
		+	<!-- The following are adjustments to the standard MediaWiki layout to customize the page display -->
		+	__NOTOC__
		+	{\| class="wikitable" style="float:right; margin-top:0px; margin-left:10px; margin-bottom:20px"
		+	\|
		+	<categorytree mode=pages hideroot=on>20Concepts</categorytree>
		+	\|}
		+	<!-- End of customization -->
	(Needed: Example Video)		(Needed: Example Video)

@@ Line 59: / Line 59: @@
 == Creating Video of the Output ==
 == Web Links ==
 == Exercises ==
 [[Category:20Concepts]]

@@ Line 31: / Line 31: @@
 One of the important things to remember about all Max objects (not just the Vizzie modules) is that you can route any outlet to multiple inlets (as long as they expect the same type of data). So, for example, you could use a FADR module to simultaneously control the speed of a movie, the saturation level of a BRCOSR and the slide rate of a SLIDR module with a single control:
-<image>
+[[Image:20Concepts-0203.jpg|border]]
 This allow you to focus on fewer on-screen controls when you are trying to perform with a Vizzie-based system.
@@ Line 41: / Line 41: @@
 First, and easiest, you can turn off any one Vizzie module by clicking on the preview image.
-<image>
+[[Image:20Concepts-0204.jpg|border]]
 When you do this, the preview image says "Effect Bypassed", and the module no longer processes the incoming video frames - reducing processing load, and also removing the processing from the effects stream.
@@ Line 47: / Line 47: @@
 Another option is to use a CLICKR object connected to the first (video) input of a module. When you turn the CLICKR on, it turns on the module processing; when turned off, it turns off the connected module.
-<image>
+[[Image:20Concepts-0205.jpg|border]]
 As with clicking the preview image, the display will show "Effect Bypassed" in the display to show that the module is not processing video.
@@ Line 53: / Line 53: @@
 Finally, you may sometimes just want to turn off a modulation rather than turning off the entire effect. You can turn off a modulation using the colored buttons next to the inlets, or you can use the CLICKR object connected to the modulation inlet.
-<image>
+[[Image:20Concepts-0206.jpg|border]]
 Using the CLICKR object allows you to be explicit about processing management, and you can also drop the CLICKR into Presentation mode so you can adjust the processing without having to expose the modules within your user interface.

@@ Line 29: / Line 29: @@
 Controlling our switcher manually might be useful - especially if we can consolidate our work to a few user controls. In order to do this, we have to look at some more of the Vizzie CTL options. There are a class of modules - CLICKR, TWISTR and FADR - that exist for one purpose: to control other functions in your patch. These modules are hooked into your patch using the same module inlets as the GEN modules, but give you manual control of these devices. They are a great way to create a custom user interface for the rest of your system.
-One of the important things to remember about all Max objects (not just the Vizzie modules) is that you can route any outlet to multiple inlets (as long as they expect the same type of data). So, for example, you could use a FADR module to simultaneously control the speed of a movie, the saturation level of the movie and the slide rate of a SLIDR module with a single control:
+One of the important things to remember about all Max objects (not just the Vizzie modules) is that you can route any outlet to multiple inlets (as long as they expect the same type of data). So, for example, you could use a FADR module to simultaneously control the speed of a movie, the saturation level of a BRCOSR and the slide rate of a SLIDR module with a single control:
 <image>

← Older revision		Revision as of 22:06, 27 March 2013
Line 37:		Line 37:
	== Turning Processes On and Off ==		== Turning Processes On and Off ==

		+	Sometimes you want to build a large network of Vizzie objects but you only need a few on at a time. There are several ways of turning off the processing without having to dismantle your patch - let's take a look at a few of them.
		+
		+	First, and easiest, you can turn off any one Vizzie module by clicking on the preview image.
		+
		+	<image>
		+
		+	When you do this, the preview image says "Effect Bypassed", and the module no longer processes the incoming video frames - reducing processing load, and also removing the processing from the effects stream.
		+
		+	Another option is to use a CLICKR object connected to the first (video) input of a module. When you turn the CLICKR on, it turns on the module processing; when turned off, it turns off the connected module.
		+
		+	<image>
		+
		+	As with clicking the preview image, the display will show "Effect Bypassed" in the display to show that the module is not processing video.
		+
		+	Finally, you may sometimes just want to turn off a modulation rather than turning off the entire effect. You can turn off a modulation using the colored buttons next to the inlets, or you can use the CLICKR object connected to the modulation inlet.
		+
		+	<image>
		+
		+	Using the CLICKR object allows you to be explicit about processing management, and you can also drop the CLICKR into Presentation mode so you can adjust the processing without having to expose the modules within your user interface.

	== Creating Video of the Output ==		== Creating Video of the Output ==

@@ Line 15: / Line 15: @@
 If we create this simple Vizzie patch:
-<image>
+[[Image:20Concepts-0201.gif|border]]
 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:
-<image>
+[[Image:20Concepts-0202.jpg|border]]
 Now, modules only get messages when they are switched in, and we are using CPU as efficiently as possible.

← Older revision		Revision as of 16:40, 5 February 2013
Line 26:		Line 26:
	== Centralized Control with User Interfaces ==		== Centralized Control with User Interfaces ==

		+
		+	Controlling our switcher manually might be useful - especially if we can consolidate our work to a few user controls. In order to do this, we have to look at some more of the Vizzie CTL options. There are a class of modules - CLICKR, TWISTR and FADR - that exist for one purpose: to control other functions in your patch. These modules are hooked into your patch using the same module inlets as the GEN modules, but give you manual control of these devices. They are a great way to create a custom user interface for the rest of your system.
		+
		+	One of the important things to remember about all Max objects (not just the Vizzie modules) is that you can route any outlet to multiple inlets (as long as they expect the same type of data). So, for example, you could use a FADR module to simultaneously control the speed of a movie, the saturation level of the movie and the slide rate of a SLIDR module with a single control:
		+
		+	<image>
		+
		+	This allow you to focus on fewer on-screen controls when you are trying to perform with a Vizzie-based system.

	== Turning Processes On and Off ==		== Turning Processes On and Off ==

← Older revision		Revision as of 03:21, 1 February 2013
Line 5:		Line 5:

	== Switching Streams ==		== 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:
		+
		+	<image>
		+
		+	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:
		+
		+	<image>
		+
		+	Now, modules only get messages when they are switched in, and we are using CPU as efficiently as possible.

← Older revision		Revision as of 19:57, 29 January 2013
Line 1:		Line 1:
		+	(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 ==
		+
		+
		+	== Centralized Control with User Interfaces ==
		+
		+
		+	== Turning Processes On and Off ==
		+
		+
		+	== Creating Video of the Output ==
		+
		+
		+	== Web Links ==
		+
		+	== Exercises ==
		+
		+
	[[Category:20Concepts]]		[[Category:20Concepts]]