Thanks for sticking around for this, part 3. Now that we've covered the basic mechanical concepts, we're going to cover a couple non-essential, but still very useful, concepts that you can employ. Remember you do not have to make use of these, but they can make a larger display easier to manage and easier to control.
More "Advanced" Concepts
What is going to be presented this week is not necessary to use Vixen 3.0. These are concepts that will allow you to refine the model of your display in the software, if you so choose.
As channel counts are rapidly increasing, and displays are getting more complex, we need to be able to group the channels into useful logical groups to more easily manipulate and control them. In addition, it is inherent in the use of effects -- as we mentioned, an effect is applied to a collection of channels (such as a megatree). The most logical way to do this is to apply effects to a single group. In addition, groups can be part of other groups, so we can easily build up a logical structure for our display that makes it easy to work with and apply effects to. Want to apply a "spin" effect to your "Megatree" group? No worries. Want to fade out the entire display? Easily done; just apply a fade effect to a group that eventually includes all channels of your display.
Groups start at the bottom level -- your channels. Take a collection of channels and create a group. Then take collections of groups and create more groups. A channel can also belong to multiple groups. If you have a group of red mini trees, those channels may belong to a "Red Trees" group as well as an "All Trees" group and maybe an additional "Front Yard" group. The idea is to build up your groups the same way you build up your display. To have all of the mini trees fade to black, you simply apply the "Fade" effect to your "All Trees" group. But what if you added some blue mini trees, created a group for them, and you want them to behave the same as the trees in the "All Trees" group? Is there a bunch of copying that you have to do? Thankfully, no. You add the blue trees group to the "All Trees" group and you're done. The software will account for them when the effect is rendered.
The concept of high-level effects accomplishes a lot, as far as capturing your intent and making the software do the hard work for you. An effect can make something complex, such as spinning a mega tree, into an easy task by doing all of the math for you. However, as it stands, the effect doesn't know one channel from another. The effect could fade from one color to another, but you would have to tell it which channel is which color and you would have to do that every time you used that effect.
The final key to the puzzle of modelling a display, and accurately reflecting a user's intent, is to give the software some sort of understanding of the properties of the channels and groups in the display: to know what they are, or how they behave. That way, the effects can act appropriately. The best way to clarify what is meant by that is probably to give some examples. A prime example might be giving a channel or group an "RGB Colour" property, which lets us define it as having red, green and blue components. When an effect is applied to that group or channel, the effect can determine that it has this property and can give the user appropriate options when configuring the effect (picking a colour, or changing colours, etc.). The key point here is that, using a property of a channel or group, we can define or model the display more accurately and make our job easier when it comes to sequencing. To continue the example, you would apply the RGB property to RGB groups that you have and identify which channel is which color (this would be done as part of the one-time display configuration). Then you apply your whiz-bang "Super Mega Tree Color Spectacular Spin Effect of Wonder" and tell it to spin at a rate of 2 Hz for 5 seconds, changing from red to green by way of yellow. With the properties applied and the effect being aware of that property, it knows how to handle the constituent channels to produce the appropriate colors.
But it's not limited to RGB or even to color. There could be properties for other color schemes or display layout. One such property could allow you to define relative spacing or positioning of elements in your display. Following the concept of modelling, you could tell it groups A, B, and C are part of the "front yard" group. Together, they span the whole front yard, but group A covers 0-20% of the front yard, group B covers 20-80%, and group C covers 80-100% of that "front yard" group. You then apply an effect that does a chase across all affected channels and you want it to do it across the "front yard" group over 10 seconds. Instead of each channel getting an equal amount of time, which wouldn't make for a smooth chase across the front yard, group A would get the first 2 seconds, group B would get the next 6 seconds, and group C would get the last 2 seconds. The result more closely follows your intent.
These are just a couple examples of what we're trying to provide with properties. There will be a few canned properties available, but we encourage people to develop new ones. If history is any sort of a guide, we're going to be seeing properties and effects come from the community that we couldn't have possibly conceived.
Scripting is still around. This doesn't really fall within the realm of helping you to model your display, but it's also a more advanced topic and not necessary for basic operation. So welcome to a quick scripting overview. There are a few changes:
1. VB support, as well as C#. And, if anyone gets the urge to develop the modules, any .NET-supported language. For now, those two languages should cover pretty much everyone's requirements. And, yes, it does have to be a .NET-supported language. Hey, just be happy that we went beyond C# and that they're modules now.
2. So far, anything you can do in a classically authored sequence you can do in a script. Scripts have access to the same set of groups, channels, and effects that every other sequence type does. I say "so far" because, so far, those three things are all that's needed to create a sequence and scripts support them.
3. Scripts are first-class sequence objects now. That means you will be able to schedule them or otherwise use them in the same way you would use other sequences.
That's a quick overview, just to let you know it's still around.
This, week three, concludes the user side of things. Of course there's more than we've outlined, but this will get you thinking in the right direction. Next week, we will outline the types of modules that exist (there are 15 of them), what their roles are, and some high-level module implementation concepts. Again, not anything terribly detailed, but something to give you an idea of what to expect if you wanted to port an existing module or write your own.
Thanks for reading!