Nutcracker: First pass of LSP file

[ptone]

Not long same as other LOR imports. I have version 2.0.11271.743 on a 5 year old Dell E6500 Laptop with Core 2 Duo processor

When i loaded the 20 mbyte file in LOR it took 8 seconds

egads - 1 model, 10 seconds = 20 MB

now I deal with multi-gig video files all the time, but still, these are ultimately going to be huge data files when you are talking about a whole show.

-P

[smeighan]

Not long same as other LOR imports. I have version 2.0.11271.743 on a 5 year old Dell E6500 Laptop with Core 2 Duo processor

When i loaded the 20 mbyte file in LOR it took 8 seconds

egads - 1 model, 10 seconds = 20 MB

now I deal with multi-gig video files all the time, but still, these are ultimately going to be huge data files when you are talking about a whole show.

-P

Yep, not alot i can do. The massive rgb devices will produce massive files.

The 10 second file was from a 32x64 tree.  This tree will have 2048 pixels and need 6144 channels. I was running a 50ms frame.
I will need 122,880 bytes of info per second. In 10 seconds 1,228,800 bytes of RGB. Now you have the overhead of having these bytes be in an ASCII xml file.

The 10 seconds file ended up as 20mbytes. I am expecting LSP xml file to be at least as large.

So if i create all the effects for a megatree for a 3 minute video, 600mbytes of xml.

I am hoping RJ's conductor might offer a way to save some of this.

Also dont try 25ms frame timing unless you really need it. That would double the size of the file.

If there is intelligence in the xml that would allow looping parts, i could take advantage of that in a future export.

I already have logic so that i dont output data if the rgb value is zero

Here is a sample
<channel name="R1-P3-G" color="65280" centiseconds="10000" deviceType="LOR" unit="1" circuit="8" savedIndex="4">
<effect type="intensity" startCentisecond="50" endCentisecond="55" intensity="15" />
<effect type="intensity" startCentisecond="55" endCentisecond="60" intensity="50" />
<effect type="intensity" startCentisecond="60" endCentisecond="65" intensity="88" />
<effect type="intensity" startCentisecond="65" endCentisecond="90" intensity="100" />

Notice all the overhead to finally be able to start outputting the GREEN value for this string.

Most of the nutcracker animations do one cycle and then repreat. sure is a waste of speace to keep sending out the same animation sequence, say 6 times.

i do believe space management is going to be something i will try to work on.


Maybe LSP 3 (summer 2012) and LOR S3 have some xml features that allow the files to be smaller.

thanks

[taybrynn]

I think we are already seeing that very large RGB sequences (hopefully turbo charged with Nutcracker effects in 2012) ...  are likely to require some kind of hardware based playback, like what the etherdongle conductor daughter card would allow for  This means that regardless of whether I'm using LOR, LSP ... I might be converting my sequences into .xseq and putting it onto a memory card for playback.  It least based on the reports from RJ that he's playing very large sequences with zero lag ... which is AWESOME !

After experiencing more lag than I've ever seen before last year, I'm convinced that you must minimally use DMX / or /  PIXELNET & DMX as the protocol ... as LOR protocol (on half my show)  was the main bottleneck for me, even using only approx. 1 pixelnet universe of channels.  As soon as I switched to DMX control over those same LOR controllers, using the same base sequences,  the lag went away ... and I saw the sequences come to life in a whole new way (for the better).  If course this all happened after Christmas, so nobody other than the fire department guys got to see it.

I also saw some lag on some distant pixelnet based SS nodes ... but I think the pixelnet signal itself was getting degraded from (crossing) bundles of power cords (because when I would turn on my neighbors roof ... lots of C9s ... lots of power ... I'd see degraded control/response in a distant pixelnet based display item in his yard) ... but once I turned his house lights down or off  ... I'd see that same display item become responsive again, without the lag..  I think once I can get the pixelnet signal insulated from the power cords (told my neighbor to do this, didn't happen)  ... the signal won't degrade and I'd get rid of that issue.  Another option might be to someday run a second etherdongle over there and use 802.xx wireless to bypass all the wiring from my house, across my yard and over his roof.