Vixen 3.0 Introduction Series - Part 3

[KC]

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.

Groups

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.

Properties

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

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!

[dirknerkle]

Well done, KC. Another well-written tome, easy to grasp and filled with possibilities. -dave

[macebobo]

Well done, KC. Another well-written tome, easy to grasp and filled with possibilities. -dave

How in the world do you do that. First response that is.

Anyhow, I would second that opinion. Still waiting with all the excitement that Christmas has to offer!

[rokkett]

+1 on the schedulable scripts...

[g2ktcf]

I am drooling!!!!

[ChiefWarrant]

Sitting on the edge of my seat....clicking refresh on the Vixen downloads page....hoping it says "Latest version: 3.0.0.0" Download now!

[sallz0r]

Sitting on the edge of my seat....clicking refresh on the Vixen downloads page....hoping it says "Latest version: 3.0.0.0" Download now!

It's not going to be *that* soon, I'm sorry to say. :-) It will at least be another month (at the very least) -- it's still under very active and heavy development.

The only reason we're discussing these sort of ideas and concepts with the community is to get a bit of feedback about what everyone thinks -- if it's the sort of thing people would like, and if they like where it's going (to make it easier to sequence displays, and to add more powerful functions and features to extend a display). It seems there's been nothing but positive feedback, though, so that's good! It means we're on the right track, and can continue working hard to try and get something to the community sometime in September (hopefully!).

[dirknerkle]

It's not going to be *that* soon, I'm sorry to say. :-) It will at least be another month (at the very least) -- it's still under very active and heavy development.


Don't rush! It can only induce bugs and long-term development issues! We'll wait!!! :grin:

[Blackbeard]

One thing I'm waiting to hear about is the Preview, how it will be set up and how it will differ from the current versions. Unless I've missed something, all this sounds great, very professional, but I still am wondering how it'll all play out as we design our layout.

I'm not pushing for a hurried explanation since there's at least one more installment coming, and maybe it'll be explained there, but so far, I'm missing how all these improvements will be used without the designing preview.

[sallz0r]

One thing I'm waiting to hear about is the Preview, how it will be set up and how it will differ from the current versions. Unless I've missed something, all this sounds great, very professional, but I still am wondering how it'll all play out as we design our layout.

I'm not pushing for a hurried explanation since there's at least one more installment coming, and maybe it'll be explained there, but so far, I'm missing how all these improvements will be used without the designing preview.

No, no, that's a very valid question.

There's been a few ideas floating around, but nothing in concrete yet. Since it's going to be a very modular system, it's the sort of thing that can be expanded on later if needed. But for now, to help with the development of it, and in the spirit of community feedback, let me turn the question back on you -- how would you like to use it? :-) Or, another way to look at it -- what is wrong with the current preview in 2.x that you would change if you had the chance?

(no guarantees on anything, but we're always keen on hearing how people want to use it. After all, it's the users that ultimately have the final say on if they like it and will use it!)

[Virtus]

Which DIYC members are members of the development team for Vixen 3.0?

[blantrip]

No, no, that's a very valid question.

There's been a few ideas floating around, but nothing in concrete yet. Since it's going to be a very modular system, it's the sort of thing that can be expanded on later if needed. But for now, to help with the development of it, and in the spirit of community feedback, let me turn the question back on you -- how would you like to use it? :-) Or, another way to look at it -- what is wrong with the current preview in 2.x that you would change if you had the chance?

(no guarantees on anything, but we're always keen on hearing how people want to use it. After all, it's the users that ultimately have the final say on if they like it and will use it!)


It would be nice if there was a more powerful graphics editor such that more detailed lines or symbols representing the display could be added to the jpeg. Or maybe be able to use an exernal graphics editor and import the picture with the lines and symbols added. Not sure if the import feature with lines would be possible.

The other thought is to have symbols for arches, mega trees, etc, be automatically generated based on the setup. (e.g., if it is a mega-tree with 2 colors, and x number of channels per color, the mega tree symbol could automatically be a picture and be able to be re-sized to be the appropriate scale.

Also with the increasing prevelance of RGB floods and other display elements, maybe allow drawing a rectangle or circle that could approximate the flood coverage area and show the appropriate colors to match the sequence.

This may get to detailed to be rendered on the fly, so maybe an option to export it as an mpeg, along with the music, so the final (or at close to the final sequence) can be viewed with more detail.

Just dreaming. :)

[KC]

Which DIYC members are members of the development team for Vixen 3.0?
I'm missing some DIYC member names, but so you can recognize them, sallz0r, dynamoben, and jonathanreinhart are among them. There are two more guys, but I don't know their member names and I don't want to out their real-life names (again) out of a respect for their privacy (sorry for doing that once, guys).

[Mactayl]

I'm missing some DIYC member names, but so you can recognize them, sallz0r, dynamoben, and jonathanreinhart are among them. There are two more guys, but I don't know their member names and I don't want to out their real-life names (again) out of a respect for their privacy (sorry for doing that once, guys).

I am thinking that folks should just lay back and see what KC and the team can produce, I am sure this is a hard enough task as it is. We all want something new but this task is very involved and I am sure it takes many man hours to produce Vixen 3, so lets wait and see what they come up with and I am sure it will blow all of our socks off.;)

[KC]

...and see what they come up with and I am sure it will blow all of our socks off.;)
BREAK OUT THE HIGH-OCTANE COFFEE!

No, no mug, just right in the ol' aorta. Thanks.

[Virtus]

I'm missing some DIYC member names, but so you can recognize them, sallz0r, dynamoben, and jonathanreinhart are among them. There are two more guys, but I don't know their member names and I don't want to out their real-life names (again) out of a respect for their privacy (sorry for doing that once, guys).

Thank you, KC. I want to be able to thank them all when the time comes.

[Blackbeard]

But for now, to help with the development of it, and in the spirit of community feedback, let me turn the question back on you -- how would you like to use it? :-) Or, another way to look at it -- what is wrong with the current preview in 2.x that you would change if you had the chance?


There's nothing wrong, in my opinion, with the current preview and layout design. It's a little time consuming to put 100+ channels on an image, but maybe that's the price you pay for a lot of channels. As someone who has only put together a few previews - a new one for each year I've used Vixen - some of the functions and options are not intuitive. Things like pixel size, etc. I see a lot of the same questions concerning the preview being asked on the forum, so I'm guessing I am not alone.

There are some really good suggestions from past versions and I'm starting to see new suggestions for the upcoming version. The fact of the matter is that Vixen is a really good piece of software and could stand as is to get the job done. I don't have the vision the creators have for this, so I'm sure whatever they decide will be fine. I'm a programmer by trade, and realize that what I envision as an interface is not always intuitive for the end users, but once they use it, it usually works out.

I can't think of much to change, but my displays are simple, no RGB stuff yet, etc, so I'm not lacking in tools for what I try to do. My question was asked because I just hadn't see anything on what I feel is the starting point in current versions for any sequence.

[IdunBenhad]

Hi:
To me, the hardest part of sequencing is getting the symbols into the Visual Preview. I am a stickler for display and I have a hard time with it.

Blantrip had some good ideas and I agree with him and Mactayl.

I started a thread earlier about a display visualizer and Erik jumped on it.

Here is the preliminaries: http://code.google.com/p/vixendisplayvisualizer/

This might very well be incorporated into Vixen 3.0, if that is his desire.

Also, when KC and gang have time, they might want to take a look at the early Prancer ideas. Apparently Prancer is dead, but the ideas aren't. Also, Pro Light Show has a good visualizer.

This is not pressure anybody, just some ideas.

Thanks KC and helpers.

[erm213]

Hi:
To me, the hardest part of sequencing is getting the symbols into the Visual Preview. I am a stickler for display and I have a hard time with it.

Blantrip had some good ideas and I agree with him and Mactayl.

I started a thread earlier about a display visualizer and Erik jumped on it.

Here is the preliminaries: http://code.google.com/p/vixendisplayvisualizer/

This might very well be incorporated into Vixen 3.0, if that is his desire.

I plan on porting the plugin over to 3.0, unless of course, there is no need to do so because something better already exists.

For Vixen 3.0, are you guys still using WinForms, or, by chance, have you moved over to WPF?

Thanks,

Erik

[sallz0r]

I plan on porting the plugin over to 3.0, unless of course, there is no need to do so because something better already exists.

I've had a quick look just now at the display visualizer for 2.x (mainly just watching the linked video), and it looks good -- however I'm not 100% sure how well it would fit with the different approach we're taking in 3.x, and the way the display is structured and deisnged differently. Now that we have a lot of the information on the configuration of the display (the groups, how they are structured, if they are coloured and what channels make up each discrete colour, etc.), we can automate a lot of it, and we don't need to take as much time to setup those basic elements.

Having said that, I can see there's lots of other elements that can be useful as well. :-)


For Vixen 3.0, are you guys still using WinForms, or, by chance, have you moved over to WPF?

Still using Winforms. I know one reason was for its ability to be supported on other OSes via Mono, as Mono has no intentions of support WPF. I think there were some other reasons as well.

[Materdaddy]

I have a question regarding the new "effects", "groups", "properties", etc.

Are they rendered and saved to the files as event data, or are they saved as a "group", "effect", "property" data? If they're saved as pre-processed groups/effects/properties, will there be an "export" option? Or even an "auto-export"/"auto-render" option?

I'm writing some software (http://doityourselfchristmas.com/forums/showthread.php?16484-Chumby-Christmas-Controller&p=167611#post167611) to run on a small linux device for playback instead of using a laptop/desktop. The software currently reads the event data in the current vixen file format which is easily parsed and written to a serial port. Will I have to re-implement the effects/groups/property processing that vixen implements for my software to read saved vixen files from 3.0 to use them?

[sallz0r]

I have a question regarding the new "effects", "groups", "properties", etc.

Are they rendered and saved to the files as event data, or are they saved as a "group", "effect", "property" data? If they're saved as pre-processed groups/effects/properties, will there be an "export" option? Or even an "auto-export"/"auto-render" option?

They won't be rendered to the file, the effect data will be saved to be able to modify effects later on. The way it will work is completely different to 2.x, so it's best to try not to think about it in that sort of mindset.

We've discussed export options, but that's more for sharing sequences between people, and nothing is set in stone yet.



I'm writing some software (http://doityourselfchristmas.com/forums/showthread.php?16484-Chumby-Christmas-Controller&p=167611#post167611) to run on a small linux device for playback instead of using a laptop/desktop. The software currently reads the event data in the current vixen file format which is easily parsed and written to a serial port. Will I have to re-implement the effects/groups/property processing that vixen implements for my software to read saved vixen files from 3.0 to use them?

Short answer, yes. There's nothing in 3.x that's compatible with 2.x.

Long answer, we're aiming for Vixen to be supported (in theory) under Linux (and other OSes) in future. It won't be supported out of the gate, but hopefully with Mono we can get it working on other platforms. We haven't actually done any of that work yet, but it's the intent and aim. (standard disclaimer applies!)

[Matt_Edwards]

This all sounds exciting. Great work team!
Matthew

[Materdaddy]

Short answer, yes. There's nothing in 3.x that's compatible with 2.x.

Long answer, we're aiming for Vixen to be supported (in theory) under Linux (and other OSes) in future. It won't be supported out of the gate, but hopefully with Mono we can get it working on other platforms. We haven't actually done any of that work yet, but it's the intent and aim. (standard disclaimer applies!)

Wow, thanks for the quick response!

Before the 4-week series, I heard rumors of Mono and being cross platform, but those seemed squashed last week (http://doityourselfchristmas.com/forums/showthread.php?16457-Vixen-3.0-Introduction-Series-Part-2&p=167064#post167064).

My software's aim isn't only cross platform support, but also "light weight" support. Even if Vixen were to run under Linux, it certainly wouldn't run on the embedded devices I'd like to target. (Chumby and/or Sheevaplugs). My plan is to have a small embedded linux device drive the show due to cost, geekyness, power use, etc.

Will any of the source be available, or only APIs?

One last question for now. Will the Vixen core be designed to have the "rendering engine" separate from the "do the sequencing" front end so maybe a light weight (300MHz? MIPS) machine could possibly run the rendering portion without the GUI?

[sallz0r]

Before the 4-week series, I heard rumors of Mono and being cross platform, but those seemed squashed last week (http://doityourselfchristmas.com/forums/showthread.php?16457-Vixen-3.0-Introduction-Series-Part-2&p=167064#post167064).

Aah, right -- sorry, both answers were intended to give the same impression, obviously worded badly enough that they sounded different. :-)

What I mean in both cases is that it's not ruled out, but it's not something that's being actively developed for. We're keeping it as a goal, and that's why we've done things like use WinForms instead of WPF (as Mono has no intention of supporting WPF, I believe), but we can't guarantee Mono support. It's only an intent at this stage.


My software's aim isn't only cross platform support, but also "light weight" support. Even if Vixen were to run under Linux, it certainly wouldn't run on the embedded devices I'd like to target. (Chumby and/or Sheevaplugs). My plan is to have a small embedded linux device drive the show due to cost, geekyness, power use, etc.

Gotcha. I work with embedded devices as my day job, and am more comfortable with embedded C and linux than .NET, so I know where you're coming from. :-) Unfortunately that's not the intent of 3.x, as I understand it -- I believe there's always been an implicit assumption of having a PC control it all.



Will any of the source be available, or only APIs?

That's above my pay grade. ;-) That's up to KC, it's his project, and he's been pretty adamant in the past that it's a very personal pet project of his that he likes to work on and keep close to his heart -- which I think is great, and I can completely understand. I'm a huge supporter of open source, yet I've been the same way about many of my own personal projects too. Hmm.... that's a bit of cognitive dissonance, now that I think about it....



One last question for now. Will the Vixen core be designed to have the "rendering engine" separate from the "do the sequencing" front end so maybe a light weight (300MHz? MIPS) machine could possibly run the rendering portion without the GUI?

It hasn't been designed like that. However, in future (and I'm talking a long, long way down the track) we may be able to do things like prerender a display to a file that embedded devices could use, or something like that..... I'm just thinking out loud here, take it with a grain of salt. But there may be things we can do, I'm not sure.

[deplanche]

Will the new version still be able to run off an external hard drive or jump drive, or will it require an install?

[Materdaddy]

sallz0r, thank you very much for the fast, detailed, and informative responses. I appreciate the replies as well as the work KC and all of the developers are doing for Vixen. It is a great piece of software and I know a lot of time, effort, and brain power are poured into it.

[sallz0r]

Will the new version still be able to run off an external hard drive or jump drive, or will it require an install?

No idea as of yet.

[KC]

If I may add to what sallz0r's already said...



Before the 4-week series, I heard rumors of Mono and being cross platform, but those seemed squashed last week (http://doityourselfchristmas.com/forums/showthread.php?16457-Vixen-3.0-Introduction-Series-Part-2&p=167064#post167064).


JonathonReinhart's been beating the drum for Mono support, so, like Michael said, there is the intent. It's just been a long while since anyone's run MoMA.



Will any of the source be available, or only APIs?


Just APIs at this point. It was a step forward for me to trust bringing other developers in, so one step at a time. :)



One last question for now. Will the Vixen core be designed to have the "rendering engine" separate from the "do the sequencing" front end so maybe a light weight (300MHz? MIPS) machine could possibly run the rendering portion without the GUI?

Any front-end application is decoupled from the rendering engine. The platform itself won't have any associated application and will rely on external applications and modules to provide any user interface. So there will be an assembly that implements the back-end without a front-end.

Michael mentioned the possibility of pre-rendering a show to a file for embedded use. I think (think) this is possible out of the box, with appropriate modules written. Michael may have to pull me aside and say "Man, listen, you don't know what you're saying in this," because I'm not the embedded guy, but I think it's easily accomplished.


Will the new version still be able to run off an external hard drive or jump drive, or will it require an install?

It should still be xcopyable. Nothing is registered, all binaries run within the same branch, and data can be separately located.

[Materdaddy]

If I may add to what sallz0r's already said...

Wow, a reply from the Vixen man himself! Thanks KC. I appreciate not only the software, but the willingness you have to share with the community and what your software has done for the hobby. Being new to this, it is very welcoming having such great support on the hardware, technical questions, forums, and software sides of the hobby. I appreciate it. Especially since I'm getting answers that sound good to what I want to accomplish, even if it takes time and extra development on my end.

[WireWrap]

Actually, KC's already given away the secret -- the software is done, but they're still working on the module names - such as whiz-bang "Super Mega Tree Color Spectacular Spin Effect of Wonder" !!! ;) ;)

They're having to devote a terabyte of disk space for the module name table. :shock: :shock:

(For the humor-impaired - I'm just kidding!)

Thanks so much to KC and the team - we ALL appreciate the tremendous outlay of time and effort you're all putting out on our behalf, even if we don't express it as often as we should. I can only hope that you all feel at least one-thousandth of the self-satisfaction that you deserve for all your work. :D :D :D

Thanks again, and I can hardly wait!!!!



:)