LED Animation Editor - question for all the LED-Wiz Devs...

[arzoo]

I've been working on the LEDBlinky Animation Editor and I'm about 75% complete . It's a stand-alone app (LEDBlinky plugin is not required) and it generates LWA files which can hopefully be used by any LED-Wiz enabled program.

But for full compatibility, we (the devs) must all agree on the parsing rules. Please correct me if I misstate anything here.

LWA files provide the following commands:
DUR
NUM
SBA
PBA
REP (currently only supported by LEDBlinky)

The basic parsing logic for each animation frame is as follows; read commands, light the LEDs, frame ends, wait duration. So the question is; what determines the end of an animation frame?

For CPs with only one LED-Wiz device, this is easy - the frame ends after each SBA command. I'm guessing that all the animation code out there supports this.

It's the multi-device CPs where things get tricky. In this case, we need to parse multiple PBA and SBA commands (one for each device) before the animation frame ends. So the SBA command cannot signal the end of the frame.

Here are the parsing rules I use for the LEDBlinky:

1)
A multi-device animation frame must start with a zero duration (DUR:0) and end with a duration greater than zero.

2)
The animation frame ends after any SBA command when DUR is greater than 0.
OR
After the DUR command when DUR had previously been 0 and now it is greater than 0 and at least one SBA command was executed during the DUR=0 group.

So here is a sample multi-device animation frame:
LWZ-DUR:0
LWZ-NUM:1
LWZ-PBA:0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0...
LWZ-SBA:34,0,68,0,2
LWZ-NUM:2
LWZ-PBA:0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0...
LWZ-SBA:128,12,0,50,2
LWZ-DUR:250

I guess the easiest solution would be if someone created a LWA dll that we could all use. But short of that, we need to use the same parsing logic. Let me know what you think. Thanks!

[arzoo]

Here's a screen shot of the animation editor. The UI isn't complete, but you can get an idea of how it will look. Some of the functionality is pretty cool - Layout mode lets you create a virtual control panel. No need to worry about devices or ports, just click on the buttons. It supports single, RGB or a combination of both types of LEDs. Colors can be selected using the sliders or selected from a color dialog. Using the intensity slider, you can fade any color RGB LED. You can single step through each animation or run the animation in real-time. When single stepping or running the animation, both the virtual cp and actual LEDs light up.

[headkaze]

Hey cool stuff arzoo!

Why don't we just redesign the lwa format altogether? I propose using an xml format like below. Notice in frame 2 it sends both commands to LEDWiz's 1 and 2.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="34,0,68,0,2" />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="128,12,0,50,2" />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="1,2" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1,2" Value="34,0,68,0,2" />
</Frame>
</LEDWizAnimation>

[RandyT]

I'll chime in on this one as some of what I am currently working on required me to make a decision here as well.

The LWZ-DUR command was designed as a time command, so it should probably remain as such.  So for my uses, I will be implementing a new command:

LWZ-BRK:  or a "break" command with no arguments.

The "break" command will indicate a frame separator.  The file should have an LWZ-DUR and then an LWZ-BRK command, before any of the output control commands are used, in order to indicate the start of the first frame.  Thereafter, any command encountered is executed at full speed until another LWZ-BRK command is encountered, at which time there is a pause of the duration indicated by the last LWZ-DUR command.

If no LWZ-BRK command is encountered at the beginning of the file, it can be parsed as a single device animation as was done previously.

This should allow for complete setup of the outputs across devices with proper framing, as well as fairly simple to code backward compatibility.

---

While I'm on the subject.....I just wanted to put out a brief note about the philosophy of the commands.  While most of this is pretty well-known at this point, there is probably some value to reading this.

1) The SBA command was designed to provide the fastest means of controlling the ON/OFF states of the outputs.  For the fastest animations, one would set up each output using the   PBA command and then use only the SBA command to manipulate the states.  However, this limits animations to ON / OFF states of varying colors and built-in pulse effects.

2) A more capable, but slower, method would be to use the PBA command for all animation (using a value of "0" for "OFF" and "49" for "Absolute (No PWM) ON" (and of course any intensity value in-between) and issuing the SBA command only once at the beginning with all used outputs set to "ON", and then only issuing it again when the speed of the built in pulse effects needs to be changed.  Again, the drawback is that this issues about 4x the data to the LED-Wiz due to the extra information required.

3) An intelligent mix of both the PBA and SBA commands would provide the best performance and the most streamlined animation files.  But doing so, and of course also depending on the type of features the animation editor was to offer,  might require an animation editor to have both an optimization algorithm when saving, and then a de-optimization algorithm for re-loading them into the editor.  I'm not advocating this, as I know what a nightmare this can be to make work well.  But if you are up to the task, this ability is why the communication system was designed the way it was.

Any of the above are acceptable ways of controlling the device, but care should be taken not to use a method which creates redundant commands.  With a single unit, this is not much of an issue.  But when multiple units are considered, unnecessary commands sent to every unit at every frame could start to create noticeable lag.

I'm happy to hear any comments on anything I've written here.

RandyT

[RandyT]

Why don't we just redesign the lwa format altogether? I propose using an xml format like below. Notice in frame 2 it sends both commands to LEDWiz's 1 and 2.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="34,0,68,0,2" />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="128,12,0,50,2" />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="1,2" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1,2" Value="34,0,68,0,2" />
</Frame>
</LEDWizAnimation>

I think the parser might be a little more complex, but it covers all of the bases.  I'm not well versed in all things XML.  Is there a "generic" parser than can be used in code for something like this?

Definitely throws out backward compatibility though

RandyT

[headkaze]

Why don't we just redesign the lwa format altogether? I propose using an xml format like below. Notice in frame 2 it sends both commands to LEDWiz's 1 and 2.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="34,0,68,0,2" />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="128,12,0,50,2" />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="1,2" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1,2" Value="34,0,68,0,2" />
</Frame>
</LEDWizAnimation>

I think the parser might be a little more complex, but it covers all of the bases.  I'm not well versed in all things XML.  Is there a "generic" parser than can be used in code for something like this?

Definitely throws out backward compatibility though

RandyT

Your a VB6 coder arn't you? Microsoft have a widely deployed xml library you can use in VB6 which you can read more about here. I use C# and .NET has the System.Xml namespace for parsing. I believe Delphi is well equipped for processing xml as well. There would most likely be libraries for every language as it has pretty much become the standard format for describing data.

The thing is what backward compatibility do we need? I don't think many people have made lwa's because there is no decent animation editor yet. That's why I propose a new format before anything goes ahead. I have made about 70 lwa's that I've given to other developers to release with their plugins and I can write a simple program to convert the old format lwa's to the new xml format. I'm happy to do that if we go with the new format.

[RandyT]

Your a VB6 coder arn't you? I think Howard would know a good way to parse xml in that. I use C# and .NET has the System.Xml namespace for parsing. I believe Delphi is well equipped for processing xml as well. There would most likely be libraries for every language as it has pretty much become the standard format for describing data.

I'll look into what's out there, for my own edification if for nothing else.

The thing is what backward compatibility do we need? I don't think many people have made lwa's because there is no decent animation editor yet. That's why I propose a new format before anything goes ahead. I have made about 70 lwa's that I've given to other developers to release with their plugins and I can write a simple program to convert the old format lwa's to the new xml format. I'm happy to do that if we go with the new format.

A new format will break compatibility with those very plug-ins you supplied your animation files to.  Multiple units could be supported in those through small changes in their code and would not require a complete re-write of their existing parsing system.

I guess my question is what problems do you foresee with my suggested approach?

RandyT

[headkaze]

Your a VB6 coder arn't you? I think Howard would know a good way to parse xml in that. I use C# and .NET has the System.Xml namespace for parsing. I believe Delphi is well equipped for processing xml as well. There would most likely be libraries for every language as it has pretty much become the standard format for describing data.

I'll look into what's out there, for my own edification if for nothing else.

The thing is what backward compatibility do we need? I don't think many people have made lwa's because there is no decent animation editor yet. That's why I propose a new format before anything goes ahead. I have made about 70 lwa's that I've given to other developers to release with their plugins and I can write a simple program to convert the old format lwa's to the new xml format. I'm happy to do that if we go with the new format.

A new format will break compatibility with those very plug-ins you supplied your animation files to.  Multiple units could be supported in those through small changes in their code and would not require a complete re-write of their existing parsing system.

I guess my question is what problems do you foresee with my suggested approach?

RandyT

Well once loadman chimes in (any moment now) we pretty much have the major plugin developers here. I don't think it will add much work to parsing at all. I don't mind your suggested approach, but I would rather spend 10 more minutes re-writing my parser than tacking on work-arounds to a format that was not designed for multiple devices in mind.

This is just my opinion, and I've debated lwa format changes with loadman and we even wrote you several e-mails asking your opinion (no reply). Unless you finish writing your own lwa animation editor it's probably more important what the plugin developers think at this stage. Hey you make great hardware, but you never finished writing your software!

This is just my opinion, so lets see what loadman and arzoo say as well.

[RandyT]

Well once loadman chimes in (any moment now) we pretty much have the major plugin developers here. I don't think it will add much work to parsing at all. I don't mind your suggested approach, but I would rather spend 10 more minutes re-writing my parser than tacking on work-arounds to a format that was not designed for multiple devices in mind.

This is just my opinion, and I've debated lwa format changes with loadman and we even wrote you several e-mails asking your opinion (no reply).

Honestly, it was because of the desire to change the format pretty much out of the gate.  Once one party holds that opinion as the best approach, there isn't much room for discussion on expanding the current format (as I think we might be seeing a little of right now ).  I really didn't know where others who had adopted the current format stood, so it was hard to know whether shifting gears mid-stream was an appropriate thing to do.

Unless you finish writing your own lwa animation editor it's probably more important what the plugin developers think at this stage. Hey you make great hardware, but you never finished writing your software!

I agree.  But as I am nearing the late stages of that software, what gets decided will impact what I am doing as well.  There may well be some advantage to an XML based animation format, and I don't deny it.  But I would like to make sure that you don't have to live, eat and breath code in order for people to be able to support the file format.  As it currently stands, the animation files can be pulled in from a file one line at a time, a command with a fixed length argument is compared against a couple of possibilities and that's pretty much all that's required to parse the files.  From what I have just been reading, an XML parser can be built into just about any MS language, but using it is nowhere near as simple as the current method allows.

This is just my opinion, so lets see what loadman and arzoo say as well.

Mine as well.  If everyone feels comfortable dissecting XML files and wants to re-write their existing code to do it, then I'll go that route as well.  I just don't want to put support for the device out of reach of the hobby programmer.

BTW, arzoo asked for a solution in the context of the current format, so that is what I offered.  I like his idea of a DLL to support playback, but I'm not in the position to offer a DLL.  I will consider making file playback part of the OCX though.  I debated implementing it in the single device version that was originally released, but I opted against it so that developers would be more likely to make more capable playback software (as arzoo has already started to do )

RandyT

[loadman]

'CHIME' 

I've kinda ran out of steam on discussions on this issue earlier this year (sorry RandyT) other than to say

* Nice work arzoo. Development such as this is in the spirit of the hobby.
* I like the XML style idea Headkaze . I think even a hobby dev (like me) could understand it with some examples supplied. I need to learn how to pars that anyway as the C++ coders at work use it.

At the end of the day I will support whatever Arzoo decides as he is the one doing the hard work on the software 

[headkaze]

Lol good one loadman

If we are to go with the original LWA format, I suggested in e-mail a while back to include the LEDWiz device and duration in the commands themselves.

Eg.

Code: [Select]

LWA-SBA:1,0,...,2 <-- send output to LEDWiz ID#1 and wait 0 milliseconds
LWA-SBA:2,20,...,2 <-- send output to LEDWiz ID#2 and wait 20 milliseconds
LWA-SBA:65535,20,...,2 <-- send output to all LEDWiz devices and wait 20 milliseconds
Where the first part of the command was a binary number with each bit representing the devices to send to and the second number being the amount of milliseconds to wait.

I'm still for the xml format though.

[RandyT]

If we are to go with the original LWA format, I suggested in e-mail a while back to include the LEDWiz device and duration in the commands themselves.

Eg.

Code: [Select]

LWA-SBA:1,0,...,2 <-- send output to LEDWiz ID#1 and wait 0 milliseconds
LWA-SBA:2,20,...,2 <-- send output to LEDWiz ID#2 and wait 20 milliseconds
LWA-SBA:65535,20,...,2 <-- send output to all LEDWiz devices and wait 20 milliseconds
Where the first part of the command was a binary number with each bit representing the devices to send to and the second number being the amount of milliseconds to wait.

How would the PBA commands interact with this approach?


RandyT

[arzoo]

Wow, looks like I've got a lot of recoding to do  . After we come to a consensus.

So we have 4 choices (so far);
1) My parsing rules (kinda a kludge)
2) Randy's new BRK command
3) New format (XML) as suggested by headkaze
4) Adding device value to each command.

Options 1 and 2 are backward compatible, 3 and 4 are not.

Exactly how many apps can play LWA files? Both MaLa plugins (LEDBlinky and LEDWiz), Atomic FE, Randy's new software(?). Am I missing others?

Hey Randy, are you working on a new animation editor?

[loadman]

I would not worry about backward compatability. There are no really good animations out there yet in the LWA format as there is no decent LWA editor.

I just downloaded the latest version of Atomic and it looks like Youki uses his own system (varitaion on LWA) so that is not an issue

Code: [Select]

SBA:1,17,17,32,0,2
SBA:1,85,165,42,0,2
FAD:1,48,48,52,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48
WAIT:1000
SBA:1,85,167,42,0,2
SBA:1,85,167,42,0,2
It sounds like you and HeadKaze should nut it out and Randy and I will follow I guess.

[RandyT]

Wow, looks like I've got a lot of recoding to do  . After we come to a consensus.

Hey Randy, are you working on a new animation editor?

No, I'm working on an  "old" one

The LED-Wiz software was originally supposed to take a form very similar to what you are working on.  I found myself drowning in difficulties related to dragging and dropping of the light/button representations.  It was just taking too long, so it was shelved in order to get the practical functionality in place.  Of course then came the demand for multiple units, so the demand was accommodated, but in doing so it obsoleted the approach used by both versions of my software. 

So recently, I spent about 4 days re-coding things.  My "drag and drop" issues are solved and things work exactly like I wanted them to originally. I have what I believe is a decent way to handle device and output assignments, to include multiple lights assigned to the same output,  and it's starting to look decent.  I'm still wrestling with the best way to deal with RGB's.  I've urged people all along to wire RGB's in groups of three consecutive outputs, starting with RED.  My editor will probably rely on that configuration being in place in order to support them, but I've not committed to anything yet.

All this being said, please keep up the good work on your programs.  I'm sure the two will be different enough that some will prefer one over the other for any number of reasons, so the more the merrier.  I almost didn't jump in on this discussion in case it might have dissuaded you from continuing, but I kind of needed to

I appreciate the link HeadKaze put up for the XML stuff, and I did give it a good thorough read.  But I really see it as over complicating a pretty simple task that, in the end, probably won't advance the capabilities of playback software.  And not only do you have to parse it for playback, but you have to write the file in that format as well.  Maybe it's not as bad as I am envisioning it, so I'm going to encourage everyone else to look at what would be entailed in their language of choice to successfully implement an XML file parse / creation system and decide whether it's the right thing to do.  If so, then maybe HeadKaze can put together a quick writeup showing how to both extract and create a sample frame of animation for playback of that format using the MSXML library.  If that turns out not to be the road most desired to travel, we should probably look at how to add similar functionality to the current format.  One thing from HeadKaze's format that I can see value in is a frame number.  So maybe instead of the BRK command I used earlier,  perhaps LWZ-FRM:"<framenumber>" should be considered?

RandyT

[headkaze]

Exactly how many apps can play LWA files? Both MaLa plugins (LEDBlinky and LEDWiz), Atomic FE, Randy's new software(?). Am I missing others?

How about my GameEx LEDWiz plugin?

I don't think backward compatibility is a big issue, I could write up a converter in a couple of minutes.

So we have:
- Mala (LEDBlinky/LEDWiz)
- AtomicFE
- Randy's (W.I.P)
- GameEx (PluginLCD)

I'm happy to go with the XML format, so that has my vote. Randy wants to go with his modified original format, Youki already has his own format, loadman will go with what we vote on. So I guess it depends on which way you want to take it arzoo, since you are writing this animation editor.

[SavannahLion]

If I may chime in.

I have no opinion on whether anyone uses XML or some other format of choice. I treat XML as just another tool in a toolbox.

But... I do have a gripe with XML. It seems a growing number of developers are creating software that parses/generates XML documents with little or no documentation  It may be the type of software I work with, or it may be across the board, I have no idea. But it gets pretty irritating trying to deal with an XML file trying to figure out what I should do with a bit of data that's undocumented. I can read DTD and XSD and unless the developer is doing something really hokey, it's easier to create compatible software with a schema in hand than it is trying to glean it from potentially incomplete documentation or from the XML itself.

All I ask is this. If electing to go with XML. Please include a schema (or tool, whatever) that will make it easier for those who join the game later (myself) to create and validate our own XML.

Just my two cents. Carry on as if I wasn't here.

[youki]

My 2 cents.

I didn't read in details all your post.

But, just my opinion, based on my experience.

- Forget XML

XML is : "Why do simple when we can do complex"

XML parser are always slower than others
XML parser consume always more memory than others parser
XML File are alway bigger than other --> slower to load
s
the only advantage of the XML is it 's normalized. So i can admit it is usefull to transfert data between eterogenous application , is more or less "human readable"  but that 's all.

I deal with XML since years now in my Job , as since a while everybody want put XML everywhere.. So i know what i'm talking about.

In case of a Led animation for a Front End , i don't think we really need it.

But just my opinions.  But i find Azoo's idea of standarize animation format very good.

But in case of Atomic, and i think other plug'ins, we add special  Command to control special feature.  Like my  FAD  command for instance.

I think if a good animation tool become available, i will just make a utility to convert the tool's format (what ever it is)  to my "built'in" format.



 

[arzoo]

When it comes to xml, I tend to agree with youki. My job also involves occasional xml coding - and youki's summary is valid. Xml tends to be a random access readable data format where as our animation commands require a sequential read. On the other hand, hk's xml schema is easy to view and definitely defines each animation frame.

Unfortunately my family and I are away this entire weekend - for a family get-together today and then a funeral tomorrow . So I won't be able to work on any software. Further debate on this subject is definitely welcome! I'll check back on Sunday night.

By the way, my animation code is entirely contained in a separate class, so it may not be difficult to convert to a DLL for others to use. Here's a question; should this hypothetical LWA.dll send commands to the LEDWiz directly, or just pass back the LEDWiz commands via some call-back event to the parent app?

[headkaze]

Obviously the way to deal with xml is to read the entire file into some nice OO class then write it out again when the user saves the animation. I don't think you should ever be reading and writing to an xml file directly, that is what RAM is for, you have an array of frames in memory and the user can alter them using the editor whilst they are in memory.

I don't agree with much of what Youki says about xml, I think it's a great format and I don't think the speed or size issues warrant any care. These are insignificant amounts here unless were talking files larger than 1 gig.

[arzoo]

Obviously the way to deal with xml is to read the entire file into some nice OO class then write it out again when the user saves the animation. I don't think you should ever be reading and writing to an xml file directly, that is what RAM is for, you have an array of frames in memory and the user can alter them using the editor whilst they are in memory.

I don't agree with much of what Youki says about xml, I think it's a great format and I don't think the speed or size issues warrant any care. These are insignificant amounts here unless were talking files larger than 1 gig.

The data is read into memory - regardless of the file format.

[headkaze]

Obviously the way to deal with xml is to read the entire file into some nice OO class then write it out again when the user saves the animation. I don't think you should ever be reading and writing to an xml file directly, that is what RAM is for, you have an array of frames in memory and the user can alter them using the editor whilst they are in memory.

I don't agree with much of what Youki says about xml, I think it's a great format and I don't think the speed or size issues warrant any care. These are insignificant amounts here unless were talking files larger than 1 gig.

The data is read into memory - regardless of the file format.

I'm sure you understood the concept, it's just when you called xml a "random access readable data format" that put me off. It's not. You read it sequentially. In fact in my example you don't really need the frame number since you just read the file in the order the frames appear in the file and write them back again  in the frame order.

[loadman]

Obviously the way to deal with xml is to read the entire file into some nice OO class then write it out again when the user saves the animation. I don't think you should ever be reading and writing to an xml file directly, that is what RAM is for, you have an array of frames in memory and the user can alter them using the editor whilst they are in memory.

I don't agree with much of what Youki says about xml, I think it's a great format and I don't think the speed or size issues warrant any care. These are insignificant amounts here unless were talking files larger than 1 gig.

The data is read into memory - regardless of the file format.

I'm sure you understood the concept, it's just when you called xml a "random access readable data format" that put me off. It's not. You read it sequentially. In fact in my example you don't really need the frame number since you just read the file in the order the frames appear in the file and write them back again  in the frame order.

I like the frame number 
It means anyone could manually make adjustments with notepad 

second thought maybe its not such a good idea.  If you quickly wanted to extend a animation you could cut and paste a section using notepad or whatever and randomly copy it into places...

[headkaze]

Obviously the way to deal with xml is to read the entire file into some nice OO class then write it out again when the user saves the animation. I don't think you should ever be reading and writing to an xml file directly, that is what RAM is for, you have an array of frames in memory and the user can alter them using the editor whilst they are in memory.

I don't agree with much of what Youki says about xml, I think it's a great format and I don't think the speed or size issues warrant any care. These are insignificant amounts here unless were talking files larger than 1 gig.

The data is read into memory - regardless of the file format.

I'm sure you understood the concept, it's just when you called xml a "random access readable data format" that put me off. It's not. You read it sequentially. In fact in my example you don't really need the frame number since you just read the file in the order the frames appear in the file and write them back again  in the frame order.

I like the frame number 
It means anyone could manually make adjustments with notepad 

second thought maybe its not such a good idea.  If you quickly wanted to extend a animation you could cut and paste a section using notepad or whatever and randomly copy it into places...

It's actually easier without frame numbers, if you know they are in frame order, like you say you could just cut and paste frames in notepad into any order you wanted.

[arzoo]

I'm sure you understood the concept, it's just when you called xml a "random access readable data format" that put me off. It's not. You read it sequentially. In fact in my example you don't really need the frame number since you just read the file in the order the frames appear in the file and write them back again  in the frame order.

There's no reason this thread should put anyone off - sorry if I did. XML provides for random access, a flat file such as the current LWA format does not. I'm totally fine with using xml for the animation files.

So let's finalize the schema. I agree - there's no need for the frame number. If anything, it could confuse things. I'd like to add a command which allows a group of frames to be repeated. And Youki has a FAD (fade) command. Maybe we need a FrameType value.

[headkaze]

You didn't put anyone off, no worries mate. If you call an XML file random access, then you could call an ini file random access too. On the low level the file is still read byte by byte, it just depends on the xml library you use. It might look like it's random access, but it's not.

Anyway back on topic. If were going with xml, I'll cover the repeating frames concept in xml. This is where frame numbers probably make sense now.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="34,0,68,0,2" />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="128,12,0,50,2" />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="1,2" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1,2" Value="34,0,68,0,2" />
</Frame>
<Loop Frame="2" Times="5" />
<Goto Frame="1" Times="2" />
</LEDWizAnimation>

Note the addition of a new command called "Loop" that can loop a frame a number of times. I also show Goto frame for jumping the play position to any frame. These are just examples of way to do something like that, but of course it could be done in a number of ways.

I think a good way to conceptualise an animation editor/player for LED's would be to look at Flash and how it's editor works and have a basic version of that.

[arzoo]

You didn't put anyone off, no worries mate. If you call an XML file random access, then you could call an ini file random access too.

Yes, I would consider an ini file random access. That's because the libraries that provide xml or ini parsing all provide random access functions.

On the low level the file is still read byte by byte, it just depends on the xml library you use. It might look like it's random access, but it's not.

And you are totally correct here. But this could be said for any data access. DBs use index files and optimized search algorithms, but often it still comes down to a byte by byte search. Anyway, this is off topic and I believe we both understand the concepts. 

Anyway back on topic. If were going with xml, I'll cover the repeating frames concept in xml. This is where frame numbers probably make sense now.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="34,0,68,0,2" />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="128,12,0,50,2" />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="1,2" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1,2" Value="34,0,68,0,2" />
</Frame>
<Loop Frame="2" Times="5" />
<Goto Frame="1" Times="2" />
</LEDWizAnimation>

Note the addition of a new command called "Loop" that can loop a frame a number of times. I also show Goto frame for jumping the play position to any frame. These are just examples of way to do something like that, but of course it could be done in a number of ways.

I think a good way to conceptualise an animation editor/player for LED's would be to look at Flash and how it's editor works and have a basic version of that.

So back on topic. I don't see the need for the Loop command since a single frame represents a single set of LED states - looping would do nothing (unless I misunderstand your intent).

The GoTo command works well.

Do we need to allow for LEDWizID attribute with multiple values (ie 1,2,4)? How about just use LEDWizID=0 for ALL devices.

I'd also like to do away with Randy's 4 bank SBA format. We can use the same format as the PBA command (32 ports plus one for the global pulse). I think this will also help with the file readability. Of course the code will need to convert back to 4 banks when sending the actual commands - but that's easy.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,..." />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="0,0,0,0,0,0,0,1,0,0,1,1,0,0,0,..." />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="0" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0,..." />
<SBA LEDWizID="0" Value="0,1,0,1,0,0,1,1,0,0,0,0,0,0,0,..." />
</Frame>
<Goto Frame="1" Times="2" />
</LEDWizAnimation>

Lastly, Randy spoke about optimization. I think this is something that should be handled by the animation player code (not by the animation editor). It seems pretty simple - if the PBA values have not changed from the prior frame, don't resend them. With that logic, the animation files could contain the PBA and SBA for commands for every device in every frame. Again, this would make for better readability. But I'm not sure I've convinced myself with this concept.

Let me know what you all think!

[headkaze]

So back on topic. I don't see the need for the Loop command since a single frame represents a single set of LED states - looping would do nothing (unless I misunderstand your intent).

No your right there, the loop command is useless, I wasn't thinking straight

The GoTo command works well.

Yep that should cover it.

Do we need to allow for LEDWizID attribute with multiple values (ie 1,2,4)? How about just use LEDWizID=0 for ALL devices.

I like that, 0 for all, works for me.

I'd also like to do away with Randy's 4 bank SBA format. We can use the same format as the PBA command (32 ports plus one for the global pulse). I think this will also help with the file readability. Of course the code will need to convert back to 4 banks when sending the actual commands - but that's easy.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" />
<SBA LEDWizID="1" Value="0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,..." />
<PBA LEDWizID="2" Value="0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0" />
<SBA LEDWizID="2" Value="0,0,0,0,0,0,0,1,0,0,1,1,0,0,0,..." />
</Frame>
<Frame Number="2" Duration="10">
<PBA LEDWizID="0" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0,..." />
<SBA LEDWizID="0" Value="0,1,0,1,0,0,1,1,0,0,0,0,0,0,0,..." />
</Frame>
<Goto Frame="1" Times="2" />
</LEDWizAnimation>


I agree with this point also. Unless your proficient in binary numbers and have a calculator handy it's pretty hard to write by hand. I like your idea there, we can always repack the data into 16 bit values when we send them to ledwiz.dll.

Lastly, Randy spoke about optimization. I think this is something that should be handled by the animation player code (not by the animation editor). It seems pretty simple - if the PBA values have not changed from the prior frame, don't resend them. With that logic, the animation files could contain the PBA and SBA for commands for every device in every frame. Again, this would make for better readability. But I'm not sure I've convinced myself with this concept.

Yep this can be handled by the player I guess. Otherwise someone who painstakenly makes an animation file by hand, your editor will optimize it and turn it into unreadable mush. So yeah, the player should do the optimizing. It's not hard, just store current state and intensity values, and only send the command if they need changing. I don't think there is a huge need for optimization though. As long as you don't run the animation too fast there should be enough time for USB 2.0 to handle the data.

Although I don't think you should have PBA and SBA commands for every device in every frame though. Only add them for a device if they are changed in the editor. But don't bother with any optimizations. I'm not exactly sure how to implement this well in an animation player, but I guess the way to do it is when the user is editing the state or intensity of a particular LED, check the last frame and only save the data if it differs. This will be a sort of be like a realtime optimization but only checking the last frame.

So there will an option for each frame I guess called "Send to all LEDWiz devices", so when you edit an LED it will effect the same outputs on every other LEDWiz. If you turn off the option and change a value for state or intensity it will check the last frame and if it differs add a new SBA or PBA command for that LEDWiz device.

Overall though I think were on the right track.

[arzoo]

Excellent 
Unless anyone else (loadman, youki, RandyT) has any objections, I'm going to move ahead with the new LWA format. We can tweak it as we go if necessary.

[headkaze]

Just one last thing I forgot to add, instead of having the GlobalPulse value inside the Value attribute, move it into it's own attribute for readability sake.

Eg.

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<Frame Number="1" Duration="10">
<PBA LEDWizID="1" Value="0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
</Frame>
</LEDWizAnimation>

[loadman]

 ...  Only if you are still having fun!

[RandyT]

Maybe I'm missing something, but this really seems like we're just adding 2 extra levels of translation for no apparent reason.  The DLL's and OCX's out there accept data in the current PBA and SBA form.  There's a reason for that....it's pretty much exactly the format in which the data is sent to the hardware.

As things were, animations were designed and then saved in the data format that could pretty much be handed directly to the DLL or OCX, which then passed it onto the hardware.  With what has been proposed, the animation program will need to manage two versions of the animation. One that actually gets sent to the hardware for display purposes, and then the XML file.  I suppose that everything could be passed through the XML generation / parse routines at save and load time and still be handled natively as before during design and playback, but I guess I'm struggling with the "whys" of inserting more processing in between.

Something else to consider.  Originally, I had also started working on some simple "scripting" style commands where small animations could be kept in individual files and a script would dynamically load the files and play them  This would allow for streaming directly from the files if so desired.  With an approach of needing to load in XML files in their entirety and then parse them before playback, there could be delays between files that would negate the ability to do things like this.

I guess I'm too old school when it comes to things like this and would probably feel better about it if someone could please tell me how a this change will benefit users and developers in the end. 

RandyT

[headkaze]

First of all I dont think any decent programmer here isn't oldschool.

Were talking about changing the SBA command so it's reable and editable from notepad. Right now you have to convert a 16 bit integer using binary and that is just too hard for the average user. Now converting a string to a 16 bit integer on the other hand is one line of code. It's worth doing just for readability's sake.

We are converting a text format to the data that is sent to the ledwiz.dll. Having the data closely resemble what is  sent to the dll and what is in the text file provides no benefit at all. Perhaps it's a benefit to the programmer, but any decent programmer can convert 1,0,1,1 to a binary number of 11. More processing inbetween is for the benefit of the end user, not the programmer.

Again when someone talks about delays in dealing with xml files I have to completely dismiss them as illinformed. If processing an xml file takes you more than a second your not doing it right. Were talking a couple hundred k's for an xml animation file here, it shouldn't take half a heartbeat to process.

At the end we are creating a format that is both easy to understand for the end user, and easy to process for the programmer. If you have issues dealing with xml, read up on it. I know new concepts in programming can be overwhelming at first but you will thank me once you figure it out. Parsing Xml is a skill you will come back to all the time, and something worth learning if your serious about programming.

The reason xml works for this project is simple: it has all the attributes in a file format needed for the job. The original format is not good enough for what is needed. Again, I have to fly my opinon flag, because I don't want to sound like I think I know more than anyone else.

[RandyT]

First of all I dont think any decent programmer here isn't oldschool.

Were talking about changing the SBA command so it's reable and editable from notepad. Right now you have to convert a 16 bit integer using binary and that is just too hard for the average user. Now converting a string to a 16 bit integer on the other hand is one line of code. It's worth doing just for readability's sake.

The SBA command is 4 bank, 8-bit representation each of the outputs, not a 16 bit integer.  And why does anyone really worry too much about building this by hand in notepad?  If that's really your concern, keeping track of the syntax in XML will be as difficult if not more so for average users.

More processing inbetween is for the benefit of the end user, not the programmer.

But I'm still unsure of what that "benefit" is to the end user.  Unless it is to  make it "human readable" and I'm still wondering why that is a benefit since it doesn't do humans much good to read it.  That is why the editors are being built in the first place, to keep users from needing to deal with these types of things manually, correct?

Again when someone talks about delays in dealing with xml files I have to completely dismiss them as illinformed. If processing an xml file takes you more than a second your not doing it right. Were talking a couple hundred k's for an xml animation file here, it shouldn't take half a heartbeat to process.

Well, a second is a long time when transitioning between short files you are streaming with a script.  Maybe it doesn't take that long, I don't know.  Have you used XML in this capacity in the past to say definitively what impact it could have?

At the end we are creating a format that is both easy to understand for the end user, and easy to process for the programmer.

If we all do our work well, the end user should never have to open a file to look at it manually, so again I have to question that as "value."  And IMHO. it doesn't make things easier for programmers, it just adds more complexity to the projects.

If you have issues dealing with xml, read up on it. I know new concepts in programming can be overwhelming at first but you will thank me once you figure it out. Parsing Xml is a skill you will come back to all the time, and something worth learning if your serious about programming.

I can write a custom parser and generation routines that will handle that simple schema as quickly and with far less overhead than the MSXML libraries, and that's probably the approach I would take.  It's just more work that I question the value of.

The reason xml works for this project is simple: it has all the attributes in a file format needed for the job. The original format is not good enough for what is needed. Again, I have to fly my opinon flag, because I don't want to sound like I think I know more than anyone else.

And how is it not "good enough"? I don't mind that you have that opinion, I would just like to know the reasons for it.  There are several methods that provide the functionality sought without having to deal with an intermediate file format.  How are these inadequate in the "big picture" of things?

RandyT

[arzoo]

Randy,
In regards to the SBA format - I agree that users may never look at the actual data when using the editor (although I'm sure some will). The need for better readability benefits us, the developers. We're the ones providing software support. If a user is having problems getting an animation to work with my plugin, I'm going to ask that they send me the file. And if I can visually understand what's going on, I can figure out what the problem is faster.

All the conversions from string data to the LED-Wiz function parameters should occur when the file is first loaded (into a memory resident data structure) - so there's no performance issue.

As for the decision to go with XML, I think it better encapsulates the animation frame structure.

I do realize that these decisions will require all of us to rework our code, but if we want to improve the layout, now is the time to do it, before there's a huge base of LWA files.

[youki]

I'm going to ask a stupid question, but why you need frame?

I see the utility of frame in tool like Flash or other animation tool and video editor but here we have just leds.

you just have to define what led are on or off , pba value for colors , and the time you want wait in this state.  Then you go the next state and change the led ..Etc...

You plan to set a Frame rate  ?  I would mean if  your animation take 10 seconds , with a framerate of 1 frame/s for instance , you will have to 10  frames definition where you would need one definition and a wait of 10 seconds?

May be i miss something, but i have the feeling you doing complex things for nothing.

May be you want synchronise led animation with video? In that case it could make sens.

[arzoo]

I'm going to ask a stupid question, but why you need frame?

I see the utility of frame in tool like Flash or other animation tool and video editor but here we have just leds.

you just have to define what led are on or off , pba value for colors , and the time you want wait in this state.  Then you go the next state and change the led ..Etc...

You plan to set a Frame rate  ?  I would mean if  your animation take 10 seconds , with a framerate of 1 frame/s for instance , you will have to 10  frames definition where you would need one definition and a wait of 10 seconds?

May be i miss something, but i have the feeling you doing complex things for nothing.

May be you want synchronise led animation with video? In that case it could make sens.

The frame concept is necessary when controlling multiple LED-Wiz's. I believe the original format was only intended to control a single device. Later, the NUM command was added, but additional logic is required to determine when a frame ends and the delay should occur.

I started this thread so that we could all agree on the parsing rules. I hadn't intended to redesign the LWA layout. But it seems that a majority of the devs are willing to do so, although we don't have total agreement (do we ever? ).

[RandyT]

Randy,
In regards to the SBA format - I agree that users may never look at the actual data when using the editor (although I'm sure some will). The need for better readability benefits us, the developers. We're the ones providing software support. If a user is having problems getting an animation to work with my plugin, I'm going to ask that they send me the file. And if I can visually understand what's going on, I can figure out what the problem is faster.

Again, IMHO, a more complex format doesn't really help that goal.  Looking for missing brackets, backslashes, misspellings in extra commands, etc don't make debugging easier, rather more difficult.  And in the case of the SBA files, having the output states represented in just 4 values seems infinitely more simple than wading through the 63 1's, 0's and commas.

All the conversions from string data to the LED-Wiz function parameters should occur when the file is first loaded (into a memory resident data structure) - so there's no performance issue.

I was referring earlier to the possibilities for streaming of data directly from discrete animation files via scripting.  This is where I would like to see some data regarding the inter-file delays that might be caused by the initial load and parsing of a file before playback can begin.  If the added time is in 10's of milliseconds, then no big deal, but approaching a second or more could cause things to get ugly during that type of playback.  Believe it or not, these types of possibilities were carefully considered when deciding on the format of the data.  I suppose a folder full of animations could all be pre-loaded into memory and indexed before hand, so long as doing so also didn't create a large lag at start of playback.

The current file format was created very much to facilitate streaming, which a custom XML parser could still accommodate.  But perhaps not so much if MSXML libraries are used?

As for the decision to go with XML, I think it better encapsulates the animation frame structure.

Perhaps from an HTML coder's readability standpoint, but again, how it that different than seeing everything between two FRM command as a frame?  Same result, less punctuation.

RandyT

[rockin_rick]

I've been following along with this and here's my opinions... (OK, I hear Stewie saying "Whhhooo the hell are youuuu?"  (For reference my background on this is - I don't know XML, don't own a LEDWiz (yet?), nor really checked out the LEDWiz packet structure until reading this thread.  My only programming experience is with PIC microcontrollers.)

I agree with Randy that the change to XML is just adding a level of translation to the mix.  The XML format proposed is only a repackaging of the current system.  I think that it needs to go one step further and allow flexibility and simplicity. 

The glaring problem that I see is that the new format doesn't address the issue of the hard coding of the LEDWiz wiring to LEDs.  The XML locks in a user to a specific wiring pattern and prevents the user from re-wiring a control panel, or allowing a specific animation file to be shared with others, unless their panel is wired exactly the same.  I think that the XML format should allow outputs (e.g. a lit button, lit trackball, etc) to be defined in the beginning of the XML as to what LEDWiz they are attached to, along with what ports they use.  Then have the frame data reference the output number and the value.  This would allow easy changes if someone decides to change their wiring, and also (perhaps more importantly) allows animations to be more easily shared.  Not everyone is going to wire their LEDs the same, and simply just swapping around assignments in the XML will make the animation work easily.

Since the XML format was going to need the XML converted to LEDWiz functions anyway, it could just take on the task of substituting the LEDWiz IDs and ports into the frames.  This does away with the (as most users would see it) cryptic and complex PBA, SBA, etc commands.  This will also have the effect of simplifying the XML to cause less user issues, and hopefully less support will be needed from devs.  I don't really see the need to have that data in the XML if it's going to have to be translated later anyway...

Youki - I think the frame is also necessary as it is/can be used as a label allowing goto's back into the animation.

Headkaze - I think that your Loop command (that was abandoned) is useful.  I just think that maybe the goto and loop were mixed together a bit.  I added back in your loop and goto into my code below.  This would cause the frame sequence to be - 1,2,3,4,3,4,1,2,3,4,3,4,1,2,3,4,3,4,1,etc


Admittingly, I don't understand the impact to what some of you are doing or have already done...  And, I don't know XML, so my XML below is probably not formatted correctly, but it is shown for the jist of my point/idea.  Most likely modifying the outputdefine data and such will be necessary...

Maybe the output1, output2, etc could be standardized into buttonP1, buttonP2, etc.  Haven't really thought that through....

Rick

Code: [Select]

<?xml version="1.0"?>
<LEDWizAnimation>
<OutputDefines>
<Output Number="1" LEDType="Single">
<LED LEDWizID="1" LEDWizPort="1">
</Output>

<Output Number="2" LEDType="Single">
<LED LEDWizID="1" LEDWizPort="2">
</Output>

<Output Number="3" LEDType="LED">
<LED_R LEDWizID="1" LEDWizPort="3">
<LED_G LEDWizID="1" LEDWizPort="4">
<LED_B LEDWizID="1" LEDWizPort="5">
</Output>

<Output Number="4" LEDType="LED">
<LED_R LEDWizID="2" LEDWizPort="1">
<LED_G LEDWizID="2" LEDWizPort="4">
<LED_B LEDWizID="2" LEDWizPort="7">
</Output>

(more outputs to be defined...)
</OutputDefines>

<Frame Number="1" Duration="10">
<Output1="48" />
<Output2="0" />
<Output3="48,0,48" />
<Output4="0,48,0" />
</Frame>

<Frame Number="2" Duration="10">
<Output1="24" />
<Output2="48" />
<Output3="48,0,48" />
<Output4="48,48,0" />
</Frame>

<Frame Number="3" Duration="10">
<Output1="48" />
<Output2="48" />
<Output3="48,32,48" />
<Output4="48,48,0" />
</Frame>

<Frame Number="4" Duration="10">
<Output1="24" />
<Output2="48" />
<Output3="48,32,48" />
<Output4="48,48,0" />
</Frame>

<Loop Frame="3" Times="2" />

<Goto Frame="1" />

</LEDWizAnimation>


[arzoo]

Again, IMHO, a more complex format doesn't really help that goal.  Looking for missing brackets, backslashes, misspellings in extra commands, etc don't make debugging easier, rather more difficult.  And in the case of the SBA files, having the output states represented in just 4 values seems infinitely more simple than wading through the 63 1's, 0's and commas.

Syntax errors should be captured by the xml library when the file is loaded. Misspelled commands would cause problems no matter what the format.

Here's a lwa example in both the old and new format. Now granted, the old format could be enhanced with better frame designators, but I still think the XML is easier to read and debug.

Code: [Select]

<LEDWizAnimation>
 <Frame Number="1" Duration="250">
  <PBA LEDWizID="1" Value=" 0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0,0,0,48,0,0,0,48,0,0,0,0,0,0,0,0,0" />
  <SBA LEDWizID="1" Value=" 0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
  <PBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0,0,0,0,0,0,0,0,0,0,48,0,0,48,48,0,0" />
  <SBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,1,1,0,0" GlobalPulse="2" />
 </Frame>
 <Frame Number="2" Duration="250">
  <SBA LEDWizID="1" Value=" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
  <SBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
 </Frame>
 <Goto Frame="1" Times="5" />
 <Frame Number="3" Duration="100">
  <SBA LEDWizID="1" Value=" 0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
  <SBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,0,0" GlobalPulse="2" />
 </Frame>
 <Frame Number="4" Duration="100">
  <SBA LEDWizID="1" Value=" 0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0" GlobalPulse="2" />
  <SBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
 </Frame>
 <Frame Number="5" Duration="100">
  <SBA LEDWizID="1" Value=" 0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
  <SBA LEDWizID="2" Value=" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0" GlobalPulse="2" />
 </Frame>
 <Goto Frame="3" Times="10" />
</LEDWizAnimation>


Code: [Select]

"0"
"LWZ-REP:5"
"LWZ-DUR:0"
"LWZ-NUM:1"
"LWZ-PBA:0,48,0,0,0,48,0,0,0,0,0,0,0,0,0,0,0,0,48,0,0,0,48,0,0,0,0,0,0,0,0,0"
"LWZ-SBA:34,0,68,0,2"
"LWZ-NUM:2"
"LWZ-PBA:0,0,0,0,0,0,0,48,0,0,48,48,0,0,0,0,0,0,0,0,0,0,0,0,0,48,0,0,48,48,0,0"
"LWZ-SBA:128,12,0,50,2"
"LWZ-DUR:250"
"LWZ-DUR:0"
"LWZ-NUM:1"
"LWZ-SBA:0,0,0,0,2"
"LWZ-NUM:2"
"LWZ-SBA:0,0,0,0,2"
"LWZ-DUR:250"
"LWZ-REP:10"
"LWZ-DUR:0"
"LWZ-NUM:1"
"LWZ-SBA:2,0,4,0,2"
"LWZ-NUM:2"
"LWZ-SBA:0,12,0,48,2"
"LWZ-DUR:100"
"LWZ-DUR:0"
"LWZ-NUM:1"
"LWZ-SBA:0,0,0,0,2"
"LWZ-NUM:2"
"LWZ-SBA:128,0,0,2,2"
"LWZ-DUR:100"
"LWZ-DUR:0"
"LWZ-NUM:1"
"LWZ-SBA:32,0,64,0,2"
"LWZ-NUM:2"
"LWZ-SBA:0,0,0,0,2"
"LWZ-DUR:100"


I was referring earlier to the possibilities for streaming of data directly from discrete animation files via scripting.  This is where I would like to see some data regarding the inter-file delays that might be caused by the initial load and parsing of a file before playback can begin.  If the added time is in 10's of milliseconds, then no big deal, but approaching a second or more could cause things to get ugly during that type of playback. 

If the new format (or old for that matter) causes any problems with streaming data directly from files, it would be the disk I/O that's causing the delay. Not the data parsing.

Believe it or not, these types of possibilities were carefully considered when deciding on the format of the data.

I have no doubt - you always sweat the details. Your hardware has advanced this hobby to a new level. As has all the incredible software developed by the community!