Main > Software Forum

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

<< < (8/15) > >>

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:

--- Quote from: youki on July 23, 2007, 11:32:51 am ---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.

--- End quote ---

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:

--- Quote from: arzoo on July 23, 2007, 11:07:26 am ---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.

--- End quote ---

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.


--- Quote ---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.

--- End quote ---

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?


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

--- End quote ---

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: ---<?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>

--- End code ---

arzoo:

--- Quote from: RandyT on July 23, 2007, 12:56:49 pm ---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.

--- End quote ---
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: ---<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>

--- End code ---


--- Code: ---"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"

--- End code ---


--- Quote ---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. 
--- End quote ---

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.


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

--- End quote ---
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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version