Documentation of file formats?

[Steve Gase]

Is there a place where documentation for commonly-used formats are documented?

I'm interested in reviewing the formats for:

• LOR
• LSP2
• Vixen
• xLights

One thing that interests me...  its been suggested that xseq be used for more editing activities.  That seems to assume that xseq is rich enough to support that function.  I'm assuming that xseq is optimized for load time and it might have thrown away a lot of meta data that a sequence editor wants to carry around with the sequence.

One thing that interests me it the ability to create LSP sequences/configurations that have alternative virtual controllers.  I'm thinking that creating one controller with pixel #1 on each of 64 strings, another controller with pixel #2 on each string, etc. would allow me to create vertical effects easily.  Another sequence would create a controller with pixel #1/string #1, picket #2/string #2, etc. to aid in spiral effects...  etc.

[keitha43]

I know LMS can be opened in wordpad and notepad and LSP opened in 7-zip.

[frankr]

File format vs. what the software actually cares about are two different things, at least for LOR.  Xlights format could be used for an editing format but it all comes down to how the software handles the data. I would bet that the data used in the objects within LOR is much different than what gets output to a file.  LSP on the other hand embeds a fair amount of serialization data so it may be closer to what is stored in the objects.

In all reality what is actually in memory may or may not have anything to do with what gets written to a file. Writing and reading from files requires parsers to convert things back and forth.

What really needs to happen for sequencing software is that it needs to be written in a 64 bit format so that it can access more memory.  I am not familiar with the internal structures that LSP and LOR are using but I am willing to bet that the coders making these applications have already spent a huge amount of time optimizing there code to do as much as they can with a limited set of resources (processor and memory).

Supporting all the functionality this software provides fro us requires being able to access data elements in many different ways in order to make different activities happen quickly.  This leads to a very common tradeoff for developers, memory vs. processing power. 

I will tell you that doing what you want with LOR is pretty easy as the the format of the file is easy to interpret.  I have looked at LSPs files and there is too much serialization data in them for me to feel comfortable thinking that I can make changes to the file and expect them to work...

Frank

[Steve Gase]

I will tell you that doing what you want with LOR is pretty easy as the the format of the file is easy to interpret.  I have looked at LSPs files and there is too much serialization data in them for me to feel comfortable thinking that I can make changes to the file and expect them to work...

Do you think that exporting from LSP2 to LOR format -- and importing back to LSP2 would cause much information to be lost?  Is LOR a good format for exchanging data between apps?

[frankr]

Personally I am very fond of the LOR format.  It is mostly human readable and easy to interpret.  Currently LSP does not do a very good job of exporting to the LOR file format but if some of those kinks were sorted out I think the file format would be fine for moving things around.  That said, the XML libraries I believe that LOR, LSP and xLights use are 32bit versions.  Hence; they run out of accessible memory at roughly 2GB.  That might sound like a lot but each file probably needs 2x its saved file size in order to be stored in the internal data structure format.  The parsing tree has a great deal of overhead.

The xLights format is great at storing data efficiently but it achieves that by making assumptions based on your network definition.  That is, xLights knows that the first x channels in an xSeg file belong to network 1 and that the next y channels belong to network 2 etc...  Where x and y are your 'last channel' settings for network 1 and 2 respectively.  great for storing not so great for moving things from person to person or program to program.

This is also why some people have reported that xseg files are sometimes bigger than the associated LOR or LSP file.

If you have 4 networks each with 4096 as the last channel and a song that is 60 seconds long then the xseg file size will be:
(4096*4)*(60*20)+(512 byte header)=19.7MB
That file size will be the same for any 60second sequence created with that network file.

Where as LSP and LOR do not store anything for time periods that have no events...

Frank

[smeighan]

I am at the place now with my tool where i need to produce xml files for LSP/Vixen and LOR.

I sure wish these programs had better documentation. Feels like reverse engineering. One of my jobs at oracle Corporation is to do the migrations of acquired companies.  Many of these companies could only give us data in xml format. One company sent us a 6 million line ASCII file of xml.

We had to reverse engineer their data since the product they were using had gone out of business. Painful, but we got it done.

Now it feels like i am in that same place again.

thanks
sean

meighan.net/seqbuilder/index.php

[angus40]

Hey Steve have you tried madrix .

when it comes to effects this program is limitless , the only thing is its sticker price .

with the matrix and mapping capabilities of this program it makes sequencing a snap.