Main > Software Forum
LED Animation Editor - question for all the LED-Wiz Devs...
<< < (3/15) > >>
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: ---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
--- End code ---

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:

--- Quote from: headkaze on July 20, 2007, 06:52:40 pm ---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: ---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
--- End code ---

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.

--- End quote ---

How would the PBA commands interact with this approach?


RandyT
arzoo:
Wow, looks like I've got a lot of recoding to do  :o. 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: ---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
--- End code ---

It sounds like you and HeadKaze should nut it out and Randy and I will follow I guess.

RandyT:

--- Quote from: arzoo on July 20, 2007, 09:27:33 pm ---Wow, looks like I've got a lot of recoding to do  :o. After we come to a consensus.

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

--- End quote ---

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
Navigation
Message Index
Next page
Previous page

Go to full version