Vixen 3.0 Introduction Series - Part 4

[KC]

Modules

First thing's first. We've moved over to the 4.0 version of the .NET framework. That is all.


"Modules?"

"Modules" = Plugins + add-ins. Those two terms have been brought together under the more generic term "module" to avoid continuing to throw around two terms where one is sufficient. And, to remove any ambiguity between 2.x and 3.0, "plugins" was abandoned.


Second thing's second. We'll start out with a short explanation of the different module types that can be implemented before getting into how they're implemented.

Output

Output modules = output plugins. A controller uses one output module to interact with the controller it represents. Controllers are updated at a regular frequency and with an update, each output module receives a state as a collection of data. Data is slightly more elaborate than byte values this time around, so the controller can choose to ignore data based on its properties.

Sequence

There are two basic types of sequences -- your standard container for channel data and script sequences. A sequence module is an implementation of one of these two types. It gives identity to a specific implementation for editors to use. While one of the two types of sequences gives basic functionality to store data for execution, a sequence module implementation can extend them to add additional functionality or data (surfaced through an editor).

Editor

An editor module is a UI implementation to edit a type of sequence. The file type identity provided by a sequence module is what an editor module keys off of. A single editor can state multiple types of sequences it will edit.

Effect

An effect is the high-level data that the user interacts with. Effects generate lower-level data that is then executed. Effects can make use of properties (property modules) to help define their runtime behavior and define parameters that the user configures at design time.

Effect Editor

Since an effect can do pretty much anything, there's no way to anticipate what kind of editing needs every effect will have. An effect editor can specify effects it can edit (can be multiple) and/or it can specify parameter signatures. This allows, for example, a single effect editor that edits a floating-point value to service any effect with a single floating-point parameter.

Media

A sequence no longer specifies a single audio file to play during its execution. Instead, it is allowed to specify a list of media files to play. A media module handles the playing of the different media types (by file type). A single module can specify multiple file types. One or none of a sequence's media modules can also serve as the timing source for the sequence.

Property

Users can apply properties to groups and channels to help define and model their display. Effects can make use of these properties to direct their behavior. A property module defines the property, a self-contained attribute, along with the UI to configure it. An example is an RGB property that, when applied to a three-channel group, allows the user to assign a color to each channel. Then an effect can intelligently handle channels by their color to, for another example, transition down a color path over time.

For effects to make use of properties, they must reference the assembly that implements property types. One motivation for doing this is to allow properties to define helper methods for effects to use.

Input

Not terribly unlike 2.x input plugins. The module defines a collection of inputs that are polled. An input raises an event when its value changes and has a parameterized effect associated with it (to be written to a channel, if the consumer so chooses). This module type has been a low priority, but will be further defined and refined with community use.

Script

Script modules implement scripting languages, as was covered in a previous post. A script module provides three things:

1. Code provider - To compile the source code.

2. Skeleton file generator - Generates the partial class that the user starts writing their script within.

3. Framework file generator - Generates the partial class that implements the properties and methods available to the user's script.

Timing

I think you can figure this one out. It provides timing for a sequence (assuming the sequence is not using a media source as its timing). With timing being implemented as a module, anything can be a timing source. Time doesn't even have to be the basis of the timing. You could have a timing module that steps through execution in response to external events (such as a user clicking a button).

If a sequence does not specify a timing or media module as its timing source, a default one will be used. The default timing source is the timing module with a specific id, so that, too, is replaceable.

Trigger

Trigger plugins are back! But, they've been a bit more defined, and a bit less supported. Let me explain.

First, the "less supported" bit. Instead of imposing a scheme of how to handle triggers, that has been left completely to the utilizers of the triggers. The trigger module itself may write data to the system for execution, or maybe an application module responds to trigger events. It doesn't have to result in a sequence being executed. This also means a sequence is not necessary to have a response to a trigger.

Second, the "more defined" bit. We've tried to define a set of trigger conditions to cover most expected use cases. A trigger can be digital, specifying a set-to-reset or reset-to-set trigger condition, or analog, using thresholds and ranges as the trigger condition.

Like input modules, a trigger module defines a collection of triggers that are polled. A trigger raises an event when it goes into the set condition. There is some gray area between inputs and triggers as we try to define them, so their very definition may change over time with community input. Unlike inputs, a trigger doesn't have data associated with it. This has been another low-priority module type, so it may be underdeveloped.

App

Application modules are what used to be "add-ins". They are modules that get access to the client application, as well as the system's entry points (which any module does). A scheduler is an excellent example of an application module -- it needs to add menu items to provide users a way to interact with it (app modules are like services in that they don't have a defined user interface) and it needs to initiate execution. Any module can initiate execution, but only app modules get access to the client application's visual environment.

That covers most of the module types in brief. There are a few more, but their fate and/or definition is in jeopardy.


Basic Anatomy of a Module

A module is made up of two or three parts -- a descriptor, a module instance, and a data object. The first two are required, the third is optional. A specific module type will contain the following at a minimum and may contain more that pertains to modules of that type.

Descriptor

A descriptor is just that. It provides information such as the module's id, author, version, text description, and types of the module instance and data model.

"Abandon hope, all ye who enter without a unique ID."

Every module has a GUID id. This is its unique identifier. If you've copied someone else's module code and haven't changed the id, neither module will be loaded. You've been warned.

Data

Module data is serialized and deserialized for the module through this data object. The module defines a class as its data object and gets/sets its data through an instance of this class (which is provided for the module upon instantiation). A module is not required to have a data object.

Module Instance

An instance of the module. In most cases. Additionally, some module types will be managed as singletons, so the instance you receive may not be just your own.

Base Classes

Every module type has its own interfaces for the module descriptor and instance and every module type has a base class. This is so that you don't have to implement the same mundane members in every module you write and it allows us to provide some niceties for your use on occasion.

Dependencies

Modules can specify dependencies. This becomes helpful when your effect absolutely requires a property and won't work without it. If the property is not installed, your effect will not be loaded and you won't have to field a bunch of questions asking why your effect is so broken. But if that effect can work with and without said properties, then don't list them as dependencies.


I realize that this was a quick run-through, but I'm already a day behind on this post (and, thanks to work, a bit more behind in coding), so I gotta get this thing posted! Our hope is to follow this up with some specific examples; each week focusing on a specific type of module (starting with output modules).

I want to thank folks for following along and the continuing encouragement. If we miss our goal, it's not going to be for a lack of trying or due to lack of community response. You guys have been great and we really appreciate you all.

[macebobo]

OOOO, coder stuff. Very cool KC, et. al. I can't wait to write my first module. Again, sounds like the architecture is matching the domain which will make it easy for people to take Vixen to the next step. And, I think I can speak for many in this community, WE WANT TO THANK YOU! Without software such as this, we would either A) Be nowhere or B) Out $100 or more for commercial software.

Keep On Coding! -- John

[chelmuth]

Getting more excited each week. I need something to solder to calm me down.. thankfully dlovely is helping me out with that.. Have a great night KC Thanks for all the amazing work you and the team are doing.

[dirknerkle]

As always, a clean and clear explanation. However, the continued drool on my keyboard is starting to short out some keys... :lol:

[smartalec]

Without software such as this, we would either A) Be nowhere or B) Out $100 or more for commercial software.
No So LSP is Milking money from us now http://www.lightshowpro.com/content.php?120

KC i keep on letting everyone know about the Latest info over at ACL, Keep up the Great work.
If it was'nt for your work with Vixen, us Aussie's wouldnt be able to go crazy with mega channels
You let our dreams come true.
A Big Thankyou.

PS i keep waiting every month for the next update from you, like a little kid waiting for christmas

[Aurbo99]

KC,

So my plugin can take advantage of standard .Net 4.0 routines? (linq etc?)

[sallz0r]

So my plugin can take advantage of standard .Net 4.0 routines? (linq etc?)

Yes, that's correct.

[erm213]

KC,

So my plugin can take advantage of standard .Net 4.0 routines? (linq etc?)

I'm not KC, but the answer is yes.

Erik

[justinj]

I know Vixen 3 has had it's feature set locked, so it would be nice to get a quick rundown of what output modules are going to be available at release from the Vixen team so that those of us planning displays can make sure it'll support everything we have :)

[sallz0r]

I know Vixen 3 has had it's feature set locked, so it would be nice to get a quick rundown of what output modules are going to be available at release from the Vixen team so that those of us planning displays can make sure it'll support everything we have :)

AT the moment, there's not a definitive set; development of the basic bits and pieces is still underway.

I can't speak officially (on behalf of KC), but I might be able to provide a bit more of an idea -- we hope to get something preliminary to the community (an alpha version, if you will) soonish -- hopefully September, I think. This will have a very bare-bones feature set; a sequence editor, basic effects and properties, a display preview, and possibly some of the simple output modules (maybe a Renard, not sure what else). We don't expect this to be stable, or production-ready usable: it's an early release, purely to get feedback from the community on the style, interface, and also any bugs that are there.

Hopefully from there we can get into a pretty quick feedback/develop/release cycle, to improve it and add new modules as they're needed, and also to get the community developers involved in new output modules and other things that are needed (that we couldn't ever dream of!). Maybe -- hopefully! -- it will be in a fairly usable state for the coming season, but we know it's going to be a very close call, and everyone will be pushed for time. But as KC said in a post a month or two ago: this is only our goal, and we can't make any guarantees. We will try the hardest we can, but you have to take care of yourself first: if that means sticking with 2.x for this season, or making other contingency plans, so be it.

So, I know that's nothing definitive, and I apologize: but it's the best we have at the moment. If only we could move Christmas.... does everyone agree to just push it back a few months this year, and we'll all make it March instead? Then we can have Vixen ready for you all. ;-)

(disclaimer: I'm not KC. I can't profess to know what his thoughts are, so take this all with a grain of salt. :-) )

[justinj]

I was hoping the most common outputs would be available at release (And tuned before the season) so that we can start testing, sequencing and debugging!

Well I'll keep my fingers crossed that Renard, Generic Serial, LEDTriks and E1.31 plugins are available near release :)

[sallz0r]

I was hoping the most common outputs would be available at release (And tuned before the season) so that we can start testing, sequencing and debugging!

Well I'll keep my fingers crossed that Renard, Generic Serial, LEDTriks and E1.31 plugins are available near release :)

Yeah; hopefully they'll be not far behind, I would imagine most plugins wouldn't be that hard to rewrite. (I haven't played with any of them though, I haven't done anything in that area). But I wouldn't expect to be able to use an alpha release for anything approximating a real display; it's more for early feedback than anything else.

[justinj]

Yeah; hopefully they'll be not far behind, I would imagine most plugins wouldn't be that hard to rewrite. (I haven't played with any of them though, I haven't done anything in that area). But I wouldn't expect to be able to use an alpha release for anything approximating a real display; it's more for early feedback than anything else.

I was hoping that Alpha would be out - We can all start sequencing while they work on Beta. We continue to provide feedback and by November we'd hopefully have a stable release.

[sallz0r]

I was hoping that Alpha would be out - We can all start sequencing while they work on Beta. We continue to provide feedback and by November we'd hopefully have a stable release.

Well, that's true, but you don't need the output plugins to be able to sequence. :-) That's why we hope to have a display preview as well; it will give people something to work with for preparation.

But, again, by the very nature of an alpha software release, it's not intended to be stable or production-ready. I would suggest having a contingency plan available if needed.

[dirknerkle]

I would rather have the development team take whatever time needed and not release an alpha version at all. My experience has been that the amount of support necessary to "fix" and alpha problem for a user often detracts from working on the base code. It's fine it you have an alpha version for internal use, but don't release it. This will allow you more time to work on the important things instead of try to analyze the screwy little problems that most certainly will ensue...

Bottom line: take the time to do it right. Just my humble opinion...

[budude]

I would rather have the development team take whatever time needed and not release an alpha version at all. My experience has been that the amount of support necessary to "fix" and alpha problem for a user often detracts from working on the base code. It's fine it you have an alpha version for internal use, but don't release it. This will allow you more time to work on the important things instead of try to analyze the screwy little problems that most certainly will ensue...

Bottom line: take the time to do it right. Just my humble opinion...

However... while it may not be ready for a 2011 release, if an alpha was released while everyone has their stuff up, they could do a full scale test for a week or so and get back crucial feedback to the development team. I tear my stuff down the first weekend of January - and frankly at that point I don't/won't feel like touching anything blinky-flashy for a while... All new code will need some "burn-in" time and this would be a good opportunity to kill off the really major bugs.

[justinj]

However... while it may not be ready for a 2011 release, if an alpha was released while everyone has their stuff up, they could do a full scale test for a week or so and get back crucial feedback to the development team. I tear my stuff down the first weekend of January - and frankly at that point I don't/won't feel like touching anything blinky-flashy for a while... All new code will need some "burn-in" time and this would be a good opportunity to kill off the really major bugs.

I didn't even think of that, but that's a fantastic point. There's no point in having V3 work perfectly stable with a preview, and the moment it starts outputting data to controllers it crashes.

But either way I would like to see a useful V3 released rather than the headache that V2.5 caused a lot of people (Although I still respect the KC and the team for their hard work and dedication for the 2.5 release, if it worked well it would of been a great intermediate release between 2.1 and 3!)

[rjchu]

As much as I'd like to have a new version of Vixen to play with, note I said play with not run my 2011 show with, the former software developer and manager in me has to agree with both Dirk and Brian. Skip the alpha and instead release a beta in early December so folks can run it with their live display/controllers before teardown after Christmas (which for us is the first weekend after New Years Day). This will avoid the inevitable distraction as folks rush to implement sequences for their 2011 shows and flood the dev team with bugs or requests and allow for some "on the ground" integration testing with everyone's hardware and setup.

If the dev team feels the need for feedback on UI or layouts or things of that nature, perhaps release screenshots and scenarios/test cases and ask for feedback that way instead of releasing binaries.

Just my 2 cents to go along with Dirk's humble opinion. ;)

Thanks for all your hard work!

-Joni-

[sallz0r]

Interesting comments and thoughts. Again, I can't speak for KC, so will let him comment when (and if) he has the time; I can but share my own opinions. :-)

The reason I was making sure to stress that a first release would be an alpha release was, more or less, to manage community expectations -- to mitigate any hype, and ensure people don't think it's a fully finished product out of the gate. However, for all we know, it might be fairly good, and after a week or two of having people play around with it, test it with their controllers, making a few sequences, etc. we might call those bits/modules "stable", and people can use it for 2011. Or, it might go completely the opposite way, with everything crashing and burning. :-) I'd hope not, and I wouldn't think so, but that's the point of the early versions: to get feedback on it all as a whole, and utilize the 'community test base', if you will. :-)

Unfortunately, by the very nature of the new framework (being completely modular), it won't be a cut-and-dried switch from alpha to beta to release -- not in my mind, at least. So it's important that we get something to the community to test with so we can get those transitions happening; the only problem is that we can't schedule or guarantee when those milestones will occur. However, Christmas is a fixed point in time, and the rest of it is flexible: so I don't know if it all squishes in before Christmas, or after.

I know my few previous posts have been pretty doom-and-gloom about it all, and I apologize: I just know there's been a lot of anticipation regarding 3.x -- heck, I'm excited as hell about it too -- but I don't want everyone to assume it's good to go out of the box. It very well might be (fingers crossed), but to be sure, we need everyone's help to roll up their sleeves and test it out with us. :-)

OK, back to it... I'm working on a new sequencer at the moment, which will make sequencing a lot easier -- being able to work with effects, rather than a bunch of discrete values. :-)

[squid]

Have you thought about adding a beat detection to make design a lot easier such as:

http://www.lightjams.com/#descriptionSection
http://www.venuemagic.com/index.php/products/venuemagic-dmxav

Just a thought as log as you are releasing a new version.

[ritztech]

hopefully it comes soon .... i like how LSP looks but Holy crank its pricy :)

[Livermore-Dad]

Have you tried to use it? holy crud..

Coming from Vixen it's a friggen nightmare.

Imports for sure don't work, where is the "test channels" button? How does one add audio and when you do, why does it continue to try to optimize and not allow any blinky flashy.

I mean I'm a computer person, manage many a systems, but omg coming from Vixen and it's ease of use, LSP is a magnitude 100000000000 more difficult to just get in and get going.

Yes I love the RGB stuff, but I may end up in a divorce , lose my job, and everything else if I sat here and tried to learn it!! the price has not turned me off as I have no idea on costs at this point, but the usability omg..

Sorry Vixen thread, I would love to try 3.0 alpha, bleeding edge whatever, save me from LSP, save my marriage!

[jcdammeyer]

Hy,

I'm brand new to Vixen. I have the LOR editor and found it incredibly easy to use and was even able to get some home brew DMX lights working in addition to the TRIAC driven strings. What I don't like about LOR is that I'm limited to their devices.

My VIXEN About tells me I'm running 2.1.4.0 and that after checking it's the latest verison. Playing with it find the software somewhat non-intuitive. I expect to see a File Menu item at the far left. Then a View Menu list and so on. The designer hasn't really adheared to the CUA format for Windows. For example, which menu item shows the available attached plugins? It's availble as a toolbar called execution control but it's not clear where it is if the tool bar isn't enabled.

Would have been nice if the tarbell came with a number of 'canned' sequence files. Something with 32 channels running with Wizzards in Winter perhaps.

One of the LED projects I have done is visible here. http://www.youtube.com/watch?v=2zsVU5n0YOk That was done with 750 RGBW lamps. The one in coal harbour Vancouver had 1500 lights.

So here's the thing. LOR are non-responsive on adding other devices. It looks like Vixen may well do the job. I have a custom protocol that heads out the USB to a 9S12 controller from Freescale. From there it splits into 5 CAN bus channels, one for each ring. In the case of the coal harbour rings I had to design a new 9S12 board that also controlled power to the rings. So we had two USB ports to two 9S12s to 750 lights each.
http://www.youtube.com/watch?v=zQkfbiju8CY

The control software looked like this. Shows were stored in XML files. 11650

The advantage of the CAN bus to run the rings was that I was able to read back status information from each node.

My problem with Vixen (and LOR) is that setting up a system with 1500 channels seems a bit overwhelming. LOR seems more oriented to strings of lights of the same colour. Vixen too.

Comments?

Thanks
John

John Dammeyer

[sallz0r]

Hi John!

Good to hear from you! That looks like quite an interesting project! Thanks for the feedback regarding Vixen 2.x; it's been a while since a release now, but as you might be able to tell, we're feverishly working on a new release (3.0) which is pretty much redeveloped from the ground up, which addresses lots of issues with 2.x.

One of the major benefits is the support of more complex concepts (like colour), so it would be perfectly suited for something like what you're trying to do. Also, the other benefit is that it's completely modular in its design, so you can write a new output plugin to support your controller, and then use the software to sequence it. As it's not commercial software, there's no incentive to lock people in to particular systems (like LOR).

So, in short, sounds like Vixen would fit the bill perfectly for you! You'll just have to wait a bit for a beta version of 3.x to play around with, but hopefully you'll find it suits your needs.

[jcdammeyer]

Yes, the project was incredibly interesting and challenging. Especially since the time frame from start to delivery was less than 3 months. The second one with the barge rings was under the same time constraint, had the venue changed to battery/genset powered mid project requiring a new CPU board for the lamps and the Windows Show programmer died just as the project started.

I think the RGB addressable Christmas lights are going to become more and more available over the next few years. If the GE-35 strings can go for $50 to $75 now who knows what the price will be next year. Anyway, I see the house done with these types of lights. When I want all blue I tell all the lights to be blue. In the past this was done with sets of three strings. But say I want to wipe from Blue to Red from left to right. That's like moving a vertical line cursor across the screen acting like a paint roller.

One way to deal with that is the lights on top of photo plugin. If each light is also part of an XY array indiviudally addressable all sorts of possiblities are available. Before I discovered the Vixen software I was roughing out a similar application that let me drop lamps or strings of lamps onto a photo. On the full screen image the lights would like like coloured dots or lines. Double click and it was going to throw up a dialog with lamp parameters, XY position, Node ID, number of RGB lamps per node ID, total number of RGB Lamps.

Zoom in on the photo and the dot or line turns into a larger graphic or bit map image that makes it possible to drag, rotate, stretch and orient across the photo. I was even going to add the ability to draw lines from node to node to show the consecutive numbering. Finally the ability to play the shows on the screen.

But, now that I've found Vixen I can't see the point of writing my own. The question is this sort of thing possible by an external programmer like me or is part of the main application.

[A Marchini]

I have to admit, for light control, CAN seems a bit of overkill. Are you giving each end controller a message ID? I am just curious.
Anyways, getting a driver worked into current vixen forms should be easy. There are plug in tutorials , if you have not seen them, that you could use to generate "something".
There are some people who have display files in a repository somewhere around here in the forum. Should be able to download something there to look at.
Tony M.

[jcdammeyer]

I have to admit, for light control, CAN seems a bit of overkill. Are you giving each end controller a message ID? I am just curious.

Well, yes and no as far as overkill. There were 750 lamps each with RGBWI (RGB with White LEDs and group Intensity). The group intensity allows dimming of a particular shade without having the colour shift. The White LEDs prevented artifacts from the fact that the RGB LEDs weren't dead in line. So that's 5 channels per lamp or 3750 channels or 8 DMX universes. Each 13cm lamp was about 21cm apart on the 10m diameter rings.

To start with they were to be on the Lions Gate Bridge and consist of 100 lamps per ring. That's within the drive capability of one CAN bus driver IC. RS485 would have needed repeaters. Once the rings went to the airport (YVR) they needed to be upsized to 150 lamps and that went over the 120 node drive limit. Plus mechanically they were built in 3 segments so we ended up with 50 lamps per segment. Still over the drive capability of RS485. Since the original project was to be physically hard to reach (on the bridge) we wanted bidirectional communications and the ability to measure the node voltage and temperature.

And I've been using CAN for more than two decades. With respect to your question about IDs. Yes, like DMX-512A, each lamp has an ID and also responds to a global ID 0. Plus ID #1 is a non-configured node ID. For YVR I used a Freescale 9S12 with 5 CAN channels - one for each ring. That was cleaner than 8 Universes. It was easy to load up all five CAN channels and by the time I got back to load up the first I only had to wait around a few microseconds before I could do it again. That meant I had 75 CAN messages back to back on each of 5 CAN channels. Each message had the information for two lamps.

At 25Hz (40mS) the 9S12 spent about 50% of that refreshing the lamps. The rest dealing with the PC USB communications. Had I been able to get the DMA processor working in time I'd have had almost 100% of the 9S12 for updating the data structures. BTW, the 9S12 module has an RS485 port that will get DMX-512 support. Configuration via USB or even USB to DMX-512 and CAN? I'm open to suggestions.



Anyways, getting a driver worked into current vixen forms should be easy. There are plug in tutorials , if you have not seen them, that you could use to generate "something".
There are some people who have display files in a repository somewhere around here in the forum. Should be able to download something there to look at.
Tony M.

I'll see if I can find those tutorials.

I've just finished writing some PIC code for a slider pot module that receives CAN messages from the 9S12 (CAN bus) and clocks out the colour information to one of the SPARKFUN 32 LED RGB tapes. The code can treat the array of 32 RGBs as a single lamp all the way down to 32 lamps. In non divisible multiples like 5 lamps per node ID it figures out how to overlap adjacent LEDs like two at the end of one strip and 3 at the start of the next strip. The slide pots adjust the colours of each lamp and there's a button to handle remote or local control. I've still got to test the DMX-512A part of the code since the slider also has an RS485 input.

It's going to be pretty simple. A node ID for the DMX address held in EEROM and parameters for how many LEDs are handled with each DMX set of 3 RGB intensities. I'll probably create a custom PIC board that will have a switching regulator to provide enough current to run one 32 LED tape from up to a 40V powersupply along with RS485 and CAN capabilities.

Enough babbling.
John Dammeyer

[kychristmas]

Can you move the CAN discussion to another thread and stop hijacking this one

[smartalec]

Can you move the CAN discussion to another thread and stop hijacking this one

right on KY, i was getting my hopes up thinking ver 3 came out earlyer than they planned

[ritztech]

Is there a planned date ?? ;)

Getting all excited....

Sent from my Samsung Galaxy using tapatalk....

[sallz0r]

Is there a planned date ?? ;)

Getting all excited....

Heh, so am I. :-) The original plan was..... ooh..... a good few weeks ago now? :-(

So, is there a specific date? No: any date we give would be pulled out of....... well, you get the idea. But I know we were *hoping* for sometime towards the end of September -- that's clearly come and gone. If I had to hazard another inaccurate guess, I'd hope we *might* have a beta for people to give feedback on at the end of October? Or start of November? (my track record of estimates is 0/2, though, keep that in mind.) (Also, this isn't any sort of official comment: I leave that to KC. I'm just trying to provide a bit of feedback in his stead as I know he's super busy at the moment.)

Things are going well, though! (if anyone has a spare 13th month of the year that they can lend us, though, it would be greatly appreciated....)

[smartalec]

Things are going well, though! (if anyone has a spare 13th month of the year that they can lend us, though, it would be greatly appreciated....)

i hear ya, i need the same..
we could call it octnov..:D

[ritztech]

Im wondering if I should still wait to program for vixen 3.0 or wait till vix 3.0 for next year....

[sallz0r]

Im wondering if I should still wait to program for vixen 3.0 or wait till vix 3.0 for next year....

Aah, the forums are back up! Good to see. I haven't checked in for a few weeks because they seemed to be having troubles.

We were concerned about releasing a beta that is potentially buggy and may have problems, and have people try to use it this year. And given the feedback we've gotten, the general vibe was that people were happy to wait for something that's more solid. And, given the huge paradigm shift, I'm sure the community will have *plenty* of feedback, suggestions, and other development that will make a more fully featured product.

So, we'll hopefully be getting something out in the next week or three -- the idea was definitely something this year, that people can play with, and test out with their current display setups (before it's all taken down for the year), but not something that would be production-ready for this year.

So, in short, best to stick with 2.x for any real displays you're doing this year, but very soon you'll be able to test out 3.x for us and give lots of feedback. :-)

[gocats7]

Great news....look forward to 3.0.

[smartalec]

cant wait for version 3 to arrive, i'll be keeping my display up longer, so hopefully i get to test it with my display.
im guessing the plugin for e1.31 will still have to be written, or will it be included since everyone has started going to that?

[erm213]

cant wait for version 3 to arrive, i'll be keeping my display up longer, so hopefully i get to test it with my display.
im guessing the plugin for e1.31 will still have to be written, or will it be included since everyone has started going to that?

It is being worked on. It may not be ready for the first release, but should be shortly after that.

Erik

[fathead45]

glad to see this coming along. been holding off on upgrading my lsp as im not impressed with it much

[sallz0r]

glad to see this coming along. been holding off on upgrading my lsp as im not impressed with it much

Just out of curiosity; what don't you like about it? What things annoy you about it, or what do you want to do with it that you can't at the moment?

Similarly, what *is* good about it? ie. why are you using LSP instead of Vixen 2.x?

I'm not saying you should be using or doing anything in particular; just curious what people want to do with it, to make sure we can cater to what's needed. :-)

[g2ktcf]

Just out of curiosity; what don't you like about it? What things annoy you about it, or what do you want to do with it that you can't at the moment?

Similarly, what *is* good about it? ie. why are you using LSP instead of Vixen 2.x?

I'm not saying you should be using or doing anything in particular; just curious what people want to do with it, to make sure we can cater to what's needed. :-)

This is what makes this great! Learn from the competition and use it! ROFL

[sallz0r]

This is what makes this great! Learn from the competition and use it! ROFL

Hahaha, yeah, it sounds dodgy doesn't it? :-) Nah, I'm more thinking "make sure it does what people want it to do". I know there's a lot of fundamental changes in 3.x, and I know there's heaps more that can go into it -- but we want to make sure it at least does what people want it to do. I'd hate for people to start playing with it, and decide they don't like all the new stuff, and ditch it to go back to 2.x for some reason -- hopefully not, but hey, you never know. :-)

And, also, I'm 100% sure that people will come along, and say "hey, I want to do <x> and <y> with Vixen 3.x. How do I do that?" and it's something that we've never considered. So I figured it might be a good idea to try to cover bases.

[steve]

This is fantastic news (yeah, I'm slow--just found the news about the 3.0 development)! I think Vixen is a great application, and really the main thing I've wished for is for it to manipulate sequence data at a higher level (the vector vs pixel editor analogy as a poster mentioned in another thread), and when I decided to mitigate the other main thing I wished for (running natively on Unix) by writing my own sequencing program for Unix platforms, that's the way I set mine up because it felt like it just made more sense to me.

This is pretty cool, and I look forward to writing my own modules for Vixen 3 and using it whenever I need to use a Windows system for sequencing outputs (although I'll still work on Lumos for non-Windows use as well; at least for me that's a strong enough need to keep building that up). Having just picked up RGB lights this year, I'm very interested in the support for grouping those channels into a single logical "multi-color light" object in Vixen.