My New Sequencer

[djulien]

My feeling is right now I only need Time, EventPeriod, Levels, output channels, and EventValues. Don't need the plugin info as I will require some configuration by the user.

The EventValues are the actual cell values in Vixen. By "Levels", are you refering to MinimumLevel and MaximumLevel?

All of the <MinimumLevel>0</MinimumLevel> and <MaximumLevel>255</MaximumLevel> values I have seen have always been 0 and 255. Is there a reason for anything different?

I've used different values a few times. Since my lights are off below "20" and full-on at 220 or so, sometimes I set those as the min and max levels so that Ramp and Fade functions will start or stop at those levels. If I applied a Ramp or Fade that went all the way from 0 to 255, then there would be no visible effect at the beginning and the end, which made it look like the timing was incorrect (ie, a Ramp would end up with a delay until the lights became visible).

I've also use Min and Max to apply clipping. For example, when I had to convert some dimmed channels for use with on/off relays, I set them one apart to force a binary value, and then converted that back to 0 and 255 again afterward.

don

[frankv]

I'm going to do the conversion.

I'm going to import Vixen 2 files - convert them - so they can be played as part of my show.

Depending how they look, I may even be able to import them into my format. I would have to look at the cell pattern and see if I could match multiple cells into one of my building blocks.

Seems to me that matching multiple cells to building blocks is very similar to data compression.

Joe, I have Java source code to read both LOR and one of the several VIX formats if you want it.

Frank

[budude]

Some folks use an 80 or 90% max to save energy while still providing a relatively bright output. Over the course of a show and the several weeks it runs it adds up.

[Slite]

Suggestion:

With the Raspberry Pi looking like an interesting (and very portable) solution for running a show and Xlights being able to run on Linux... Would you look into adding possibility to export to other schedulers?

Or even better, provide the guy writing Xlights with your file specification so it can be imported into the xlights scheduler?

[JHinkle]

The EventValues are the actual cell values in Vixen. By "Levels", are you refering to MinimumLevel and MaximumLevel?



I've used different values a few times. Since my lights are off below "20" and full-on at 220 or so, sometimes I set those as the min and max levels so that Ramp and Fade functions will start or stop at those levels. If I applied a Ramp or Fade that went all the way from 0 to 255, then there would be no visible effect at the beginning and the end, which made it look like the timing was incorrect (ie, a Ramp would end up with a delay until the lights became visible).

I've also use Min and Max to apply clipping. For example, when I had to convert some dimmed channels for use with on/off relays, I set them one apart to force a binary value, and then converted that back to 0 and 255 again afterward.

don

Makes a lot of sense.

I will add the capability to my scheduler. My thought process was to address that concern through the use of dimming curves but if this alternative provides acceptable results - it's just clipping in the output stage - it has been implemented.

[JHinkle]

Suggestion:

With the Raspberry Pi looking like an interesting (and very portable) solution for running a show and Xlights being able to run on Linux... Would you look into adding possibility to export to other schedulers?

Or even better, provide the guy writing Xlights with your file specification so it can be imported into the xlights scheduler?

Absolutely.

I too use XML as the mechanism to save and transport data.

I don't use "attributes" but address each item as an individual field.

I'm still sleeping on "illumination" data - what Vixen calls EventValues. (I figure out many issues in my sleep).

I am not concerned about file size - hard drive space is cheap. For the design - I save the hi-level effect information - so it is big by its nature. The illumination data is the only place compression can take place - and if you are already big - what's a little bigger.

I can always add the capability to zip and unzip if necessary.

I also design my XML files so that they can be opened in a simple editor. You have to watch how many characters are in a line as some editors will clip the line or add unwanted characters to it.

My thoughts right now are to define a block size which contains data for a specified number of EventValues. The block would be "time stamped" as to where it belongs in the sequence and would represent the values in hex (less the 0x). example - every block describes 1 seconds of illumination data. At a sequence resolution of 25 msec - that's 40 data points at 3 characters per data point (i'm including a comma delimiter) - that line length should not cause most editors to do bad nasty things.

What I'm still pondering on is do I make provisions to exclude "black" areas of time (illumination values of 0 after being passed through a dimming curve or by applying Min/Max clipping values. What it saves in space might not be worth the effort and coding

Joe

[dowdybrown]

Absolutely.

I too use XML as the mechanism to save and transport data.

I don't use "attributes" but address each item as an individual field.

I'm still sleeping on "illumination" data - what Vixen calls EventValues. (I figure out many issues in my sleep).

I am not concerned about file size - hard drive space is cheap. For the design - I save the hi-level effect information - so it is big by its nature. The illumination data is the only place compression can take place - and if you are already big - what's a little bigger.

I can always add the capability to zip and unzip if necessary.

I also design my XML files so that they can be opened in a simple editor. You have to watch how many characters are in a line as some editors will clip the line or add unwanted characters to it.

My thoughts right now are to define a block size which contains data for a specified number of EventValues. The block would be "time stamped" as to where it belongs in the sequence and would represent the values in hex (less the 0x). example - every block describes 1 seconds of illumination data. At a sequence resolution of 25 msec - that's 40 data points at 3 characters per data point (i'm including a comma delimiter) - that line length should not cause most editors to do bad nasty things.

What I'm still pondering on is do I make provisions to exclude "black" areas of time (illumination values of 0 after being passed through a dimming curve or by applying Min/Max clipping values. What it saves in space might not be worth the effort and coding

Joe

Joe,

This is really exciting. I am the creator of xLights and I do plan to port xLights to the Raspberry Pi. Feel free to PM me with any questions you may have about xLights. Keep up the good work!

Matt

[JHinkle]

I implementing Dimming Curves.

Here are my thoughts - if you have alternate suggestion - please reply quickly because I'm locking it down.

I know there might be dimming curves already in existence. If I find the current structure acceptable - I may just use the it.

To me a dimming curve is a simple translation array - 256 in size; In the ouput stage - once an illumination value is acquired - it is used as an index into this array to acquire the illumination value the user really wants.

Each dimming curve will reside in its own XML file. The file name defines the intent of the dimming curve (example - RedLED, Incandesent, BlueLED, etc).
The dimming curve file can contain the complete 256 byte array - or only those values that deviate from the default - default being same value out ans in.

<dcv>200,235</dcv> .... this as an example of an entry int the dimming curve file - take incoming illumination value 200 and output it as 235.

These dimming curves would then be associated with a channel. If you don't use one - you get the default.

Your thoughts?

Joe

[budude]

That is how dimming curves are implemented in Vixen 2.5. A tool pops up with an initial linear graph from 0 to 255 (left to right) and you adjust that curve how you like and save it (you can save multiple curves) and then you can apply any saved curve to any one channel. It's very simple to use. Typically you would build one per light strand brand/type.

[JHinkle]

Thanks.

I was taking the easy way out for now - just use a file that someone can create in an editor or from a dimming curve generator program.

How does Vixen save its dimming curves? What format?

Joe