| Main > Software Forum |
| LED Animation Editor - question for all the LED-Wiz Devs... |
| (1/15) > >> |
| 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: ---<?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> --- End code --- |
| 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:
--- Quote from: headkaze on July 20, 2007, 04:07:15 pm ---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: ---<?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> --- End code --- --- End quote --- 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 |
| Navigation |
| Message Index |
| Next page |