KC
07-24-2011, 09:01 AM
Introduction
Welcome to our four-part presentation on Vixen 3.0. Over the next four weeks, we will try to prepare you for what you can expect in September (which we are still working hard to accomplish). We will be presenting concepts only. There won't be anything about specific editors or controllers, except in examples, and we'd appreciate it if you could restrict any questions from those specifics as well. Our goal is to try to get people comfortable with what they'll need to know in order to use the next version before they're faced with it. Also, before you ask, we're standing pretty firm on the feature set. While we would like to get everyone's request in, right now we have to focus on solidifying what's already in there.
The dev team has been discussing the best way to present this to you guys -- the end users -- and we've decided that we'll present it in 4 parts:
1) An introduction to the motivation for Vixen 3.0, including the problems that exist with the old versions (2.1 and 2.5), and what some of our goals are with the new software.
2) An introduction to some of the basic keywords and concepts of Vixen 3.0; terminology that everyone will have to understand and be familiar with.
3) Extended coverage of some of the more advanced concepts of Vixen 3.0 that people can use to control a display in more powerful ways. If you want to stick to a basic display, don't worry, you don't have to worry about these.
4) An overview of some of the behind-the-scenes bits and pieces -- the module system, and what people can contribute with. We hope that the community will get behind the software, and be able to add and extend modules to accomplish things we wouldn't even have considered!
So, to kick it off, we'll start with the motivation for Vixen 3.0: where it's come from, and what we want to do.
--
Vixen 2.x is a very useful piece of software, however over time the community requested many different features and modifications, and began to use it in ways which were not originally considered or designed for. As such, to support these new features, ideas, and concepts KC decided to redevelop the software from the ground up.
What were some of the problems with Vixen 2.x?
2.x Issues
Making/preparing a sequence was done directly to the output channels -- ie. the rows in the sequencer were directly mapped to the output channels. If you wanted to move output channels around (between controllers), or duplicate data from one channel on another, it was all done manually with lots of shuffling and copy-pasting.
Sequencing any sort of fancy visual effects were done manually by the user (for the most part). There were a few simple 'macros' hard coded into the software -- making ramps up and down, twinkle effects, etc. -- but if the user wanted to do anything complex (spinning a Megatree? pulsing stars? etc.), they had to manually program values into each of the component channels.
The software didn't have any understanding of other types of display items, such as animatronics, RGB strings, or even multi-coloured strings. All it knew of was a bunch of channels, each with an 8-bit value (from 0-255). If the user wanted to control animatronics with it, they had to make do with those values, or if they wanted to control multi-coloured lights on the same object (such as RGB strings), then it had to be done manually with different channels.
There wasn't any easy way to integrate input into the system or into a display -- there were people playing with things like Wii controllers, or Guitar Hero guitars, etc., but it was always a band-aid solution to try and get input into the system. It was always intended to be preplanned displays, output only.
Sequences were locked to individual time slices (the grid we've all grown to know and love). Anything you wanted to do was going to be fixed to a 50ms interval (or whatever time period you chose for the sequence).
The software was very defined, and not very expandable. The only real aspect that could be expanded (through modules) were Output Plugins.
Any additional functionality, such as the scheduler, was integrated into the core program. If there was a change to minor functionality, a whole new version had to be released.
So, now that we have a better idea of what the software was, and what we wanted it to be, we could start improving it. There have been many changes -- in fact, it's pretty much a complete overhaul! So how do we explain what has changed, given that a lot of people are familiar with Vixen 2.x?
Probably the key aspect to the new version is the change in approach to the user interaction. In Vixen 3.0, we are trying to capture the user's intent for a display and a sequence, rather than making the user spell out explicitly what they want to happen. What does this mean? Well, as an example, take a common display effect: spinning a megatree in a circle.
In the old version, if we wanted to do a spin on our megatree, we would have to manually figure out the channels it would apply to, the time period it would operate over, and the values for each channel in that time period to get the right brightness, fading, speed, etc. This would often take..... ages! However, in Vixen 3.0, we want to capture the intended effect for the display, instead of being forced to break it down into discrete chunks. That means (for this example) to spin a megatree, we just grab a "Spin" effect, apply it to the channels for the Megatree, and configure the effect to suit what we need (things like total spin time, number of revolutions, fade time, etc.). It makes sequencing a display a lot quicker if the software figures out what it needs to do instead of the user having to do it. You tell it "what" and it figures out "how".
As you can imagine, being able to do this requires a bit more intelligence and knowledge of a person's display setup. As such, there are a new concepts being added to Vixen 3.0 outlined in the coming weeks to better model a users display and make it quicker and easier to use.
One of the questions that has been asked many times is "what about my existing sequences?". The intent has been and continues to be to make use of your existing sequences. Being that there is such a huge shift in concepts between the two versions, you're probably going to want to do some cleanup on an imported sequence, but it will at least work. So to answer the question, we do plan on having some sort of an import wizard to bring your data into the new version.
Next week, we will begin to present and explain basic concepts and what you need to know to build a basic display and sequence.
(Thanks to Michael Sallaway for his hard work in writing most of this content.)
Welcome to our four-part presentation on Vixen 3.0. Over the next four weeks, we will try to prepare you for what you can expect in September (which we are still working hard to accomplish). We will be presenting concepts only. There won't be anything about specific editors or controllers, except in examples, and we'd appreciate it if you could restrict any questions from those specifics as well. Our goal is to try to get people comfortable with what they'll need to know in order to use the next version before they're faced with it. Also, before you ask, we're standing pretty firm on the feature set. While we would like to get everyone's request in, right now we have to focus on solidifying what's already in there.
The dev team has been discussing the best way to present this to you guys -- the end users -- and we've decided that we'll present it in 4 parts:
1) An introduction to the motivation for Vixen 3.0, including the problems that exist with the old versions (2.1 and 2.5), and what some of our goals are with the new software.
2) An introduction to some of the basic keywords and concepts of Vixen 3.0; terminology that everyone will have to understand and be familiar with.
3) Extended coverage of some of the more advanced concepts of Vixen 3.0 that people can use to control a display in more powerful ways. If you want to stick to a basic display, don't worry, you don't have to worry about these.
4) An overview of some of the behind-the-scenes bits and pieces -- the module system, and what people can contribute with. We hope that the community will get behind the software, and be able to add and extend modules to accomplish things we wouldn't even have considered!
So, to kick it off, we'll start with the motivation for Vixen 3.0: where it's come from, and what we want to do.
--
Vixen 2.x is a very useful piece of software, however over time the community requested many different features and modifications, and began to use it in ways which were not originally considered or designed for. As such, to support these new features, ideas, and concepts KC decided to redevelop the software from the ground up.
What were some of the problems with Vixen 2.x?
2.x Issues
Making/preparing a sequence was done directly to the output channels -- ie. the rows in the sequencer were directly mapped to the output channels. If you wanted to move output channels around (between controllers), or duplicate data from one channel on another, it was all done manually with lots of shuffling and copy-pasting.
Sequencing any sort of fancy visual effects were done manually by the user (for the most part). There were a few simple 'macros' hard coded into the software -- making ramps up and down, twinkle effects, etc. -- but if the user wanted to do anything complex (spinning a Megatree? pulsing stars? etc.), they had to manually program values into each of the component channels.
The software didn't have any understanding of other types of display items, such as animatronics, RGB strings, or even multi-coloured strings. All it knew of was a bunch of channels, each with an 8-bit value (from 0-255). If the user wanted to control animatronics with it, they had to make do with those values, or if they wanted to control multi-coloured lights on the same object (such as RGB strings), then it had to be done manually with different channels.
There wasn't any easy way to integrate input into the system or into a display -- there were people playing with things like Wii controllers, or Guitar Hero guitars, etc., but it was always a band-aid solution to try and get input into the system. It was always intended to be preplanned displays, output only.
Sequences were locked to individual time slices (the grid we've all grown to know and love). Anything you wanted to do was going to be fixed to a 50ms interval (or whatever time period you chose for the sequence).
The software was very defined, and not very expandable. The only real aspect that could be expanded (through modules) were Output Plugins.
Any additional functionality, such as the scheduler, was integrated into the core program. If there was a change to minor functionality, a whole new version had to be released.
So, now that we have a better idea of what the software was, and what we wanted it to be, we could start improving it. There have been many changes -- in fact, it's pretty much a complete overhaul! So how do we explain what has changed, given that a lot of people are familiar with Vixen 2.x?
Probably the key aspect to the new version is the change in approach to the user interaction. In Vixen 3.0, we are trying to capture the user's intent for a display and a sequence, rather than making the user spell out explicitly what they want to happen. What does this mean? Well, as an example, take a common display effect: spinning a megatree in a circle.
In the old version, if we wanted to do a spin on our megatree, we would have to manually figure out the channels it would apply to, the time period it would operate over, and the values for each channel in that time period to get the right brightness, fading, speed, etc. This would often take..... ages! However, in Vixen 3.0, we want to capture the intended effect for the display, instead of being forced to break it down into discrete chunks. That means (for this example) to spin a megatree, we just grab a "Spin" effect, apply it to the channels for the Megatree, and configure the effect to suit what we need (things like total spin time, number of revolutions, fade time, etc.). It makes sequencing a display a lot quicker if the software figures out what it needs to do instead of the user having to do it. You tell it "what" and it figures out "how".
As you can imagine, being able to do this requires a bit more intelligence and knowledge of a person's display setup. As such, there are a new concepts being added to Vixen 3.0 outlined in the coming weeks to better model a users display and make it quicker and easier to use.
One of the questions that has been asked many times is "what about my existing sequences?". The intent has been and continues to be to make use of your existing sequences. Being that there is such a huge shift in concepts between the two versions, you're probably going to want to do some cleanup on an imported sequence, but it will at least work. So to answer the question, we do plan on having some sort of an import wizard to bring your data into the new version.
Next week, we will begin to present and explain basic concepts and what you need to know to build a basic display and sequence.
(Thanks to Michael Sallaway for his hard work in writing most of this content.)