The NEW Build Your Own Arcade Controls
Main => Software Forum => Topic started by: arzoo on July 20, 2007, 01:11:14 pm
-
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!
-
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.
-
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.
<?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'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
-
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.
<?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
-
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.
<?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 (http://www.nonhostile.com/howto-xml-vb6.asp). 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.
-
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
-
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.
-
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
-
'CHIME' ;D
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 :D
-
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.
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.
-
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.
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
-
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?
-
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
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.
-
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?
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
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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 ;D
It means anyone could manually make adjustments with notepad :laugh2:
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...
-
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 ;D
It means anyone could manually make adjustments with notepad :laugh2:
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.
-
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.
-
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.
<?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.
-
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.
<?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.
<?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!
-
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.
<?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.
-
Excellent ;D
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.
-
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.
<?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>
-
;D... Only if you are still having fun!
-
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
-
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.
-
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
-
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.
-
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.
-
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? ;)).
-
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
-
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
<?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>
-
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.
<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>
"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!
-
rockin_rick, I actually thought about your idea - adding the Device/Port values to the animation data. But since the LEDBlinky already has an application for creating the device/port mapping it didn't make sense to duplicate the effort.
When it comes to sharing animation files - it doesn't really make sense (to me at least). Everybody's control panel is different, so the animations will all be customized for the cp layout. It's still possible to create somewhat generic animations (all on, all off, random, etc), but for those, you just send the commands to all the devices and ports.
-
Youki - I think the frame is also necessary as it is/can be used as a label allowing goto's back into the animation.
You could simply add a row number in front of the row.
But i still not really see why we need Frame. Atomic manages multiple ledwizs and i don't have Frame concept in my animation script. But don't mind, if you think it necessary , you're surely right , just my brain that is tired!
-
Syntax errors should be captured by the xml library when the file is loaded. Misspelled commands would cause problems no matter what the format.
True, however I believe "plain English" is more prone to error than is a fixed-length command format. But again, hopefully people won't need to do these things manually.
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.
At this point, it looks like the debate has moved to one of programming style. :) In my eyes, the current style seems much less cluttered, and certainly smaller in overall byte count.
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.
Then it would appear that there is indeed a concern here. If one were to script the streaming of 20 files, opening only 1 at a time as needed would mean a difference of 20x that delay at startup in XML when all files are pre-loaded, as well as more memory consumption. Of course, once they are parsed and indexed, there would be no I/O delays in the XML version. Equally, that method could be used regardless of the format, so still not really a net plus for XML.
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!
I appreciate that comment, and agree with you on the software that's been made to support the unit. Don't even consider that I might not appreciate the efforts that all of you talented folks have put into your work. I would just like to see, as Rick stated, some more tangible benefit to a new format than simple repackaging of what is already there.
I find his additions of control descriptions to be just that type of benefit. If part of the expanded animation file were to include assignments for device selection, it would indeed be the type of benefit that would warrant a re-design of the format. An animation file that included the context of the output would be a great added capability to users in swapping animations built for other control arrangements. A playback routine could even compare a record of the user's layout and offer conversion options for LWA files made for other layouts. That way, animations carried out on P1 Start or the Trackball would always be linked to those controls regardless of the panel or the quantity / ID of the LED-Wiz devices present. And when there is no match, the playback system could offer to substitute or ignore incompatible commands. Perhaps even go as far as commands like <Device="TRACKBALL" RGB="255,0,0" State="1"> As we are really talking about a system of compiling and de-compiling code, and the desire is for readability and capability, why stop just a half step into the premise?
Change can be a great thing, but change made solely for the sake of change usually isn't.
RandyT
-
I think that Randy's suggestion of having the LWA list devices, and their associated info is the best way to go. Then there could be a standard set of 'device labels' (eg - P1B1, P1B2, TRACKBALL, etc.) that the FE links to port assignments. Obviously, all FE's would need to support these device labels. This would eliminate the need for the animation editor to know the port mappings at all. Without this, the animation editor needs to know the mappings, and with it being a standalone program, it will require the user to have to input their mappings twice (once in the anim editor, and again in the FE). With a standardized set of devices, then any LWA could be used on anyones panel with any FE. Also, if a user decides to remap their LEDs on the LEDWiz, they only have to do it once in their FE. With hard coding the port mappings into the LWA, a wiring change requires that the user change their FE, and then go back and update all of their LWAs. The animation editor will also need to support that remapping.
Rick
-
Wow, when I started this thread, my animation editor was nearing completion and all I was hoping for was buy-in on a few parsing rules so that the editor would work for players other than LEDBlinky.
Those rules were a bit of a kluge because the original LWA format was never intended to control multiple devices. Suggestions were made to help address this shortcoming - new commands, xml, etc. I don't think this is change for the sake of change.
Now... holy sh*t. We're talking FE cross compatibility with standardized control labels and animation player code that uses artificial intelligence! :dizzy: Not that these aren't great ideas, but I just don't have the time. As it is my wife isn't thrilled with how much of my life has been sucked into this hobby!
If we stick with the XML format, we can always expand the schema in the future to include the Device/Port data. For now, I'm hoping a few of us are willing to agree on the format so that the editor will benefit more than just the LEDBlinky users.
-
Wow, when I started this thread, my animation editor was nearing completion and all I was hoping for was buy-in on a few parsing rules so that the editor would work for players other than LEDBlinky.
Those rules were a bit of a kluge because the original LWA format was never intended to control multiple devices. Suggestions were made to help address this shortcoming - new commands, xml, etc. I don't think this is change for the sake of change.
Well, it's something that could have been addressed with one simple new command to the existing language, and I suggested it because it was what I was actually going to use in my editor. Going to XML in order to do little more than re-package the current language is, IMHO, "change for the sake of change" :)
RandyT
-
Randy I think it's pretty apparant your against the xml format. I hope it's not because you can't be bothered re-writing your parsing code :P
Parsing xml is not slow in my experience. When I said half a hearbeat and less than a second I probably should have actually said milliseconds. I use xml for all my data file needs these days and I can parse relatively large files in fractions of a second. If you really need to know numbers parsing the ListInfo.xml file generated by Mame (26 MB) takes 1.6 seconds on my P4 3Ghz and that is using .NET's System.Xml's parser. A 3 KB file on the other hand (rougly the size a standard lwa would be) takes 0.0093 seconds to parse. So now can we end this debate on parsing xml being slow already.
Secondly I think xml is great because it is a standard format. The original lwa format is unreadable. I can look at that xml posted by arzoo and I can pretty much know exactly what it means. But I propose another change to the format for the sake of readability and that is to change SBA and PBA to the more meaningful English equivelant of State and Intensity.
<LEDWizAnimation>
<Frame Number="1" Duration="250">
<Intensity 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" />
<State 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" />
<Intensity 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" />
<State 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">
<State 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" />
<State 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">
<State 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" />
<State 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">
<State 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" />
<State 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">
<State 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" />
<State 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>
-
Randy I think it's pretty apparant your against the xml format. I hope it's not because you can't be bothered re-writing your parsing code :P
That's not it at all. I look at XML and it literally looks to me like something that uses 20 words to say what one could. It also gives me a bad feeling that less capable programmers will be shut out by it. I've never been on the side of complicating something more than is absolutely necessary, and if there is no tangible benefit in doing so, I have to say I'm against it. It should be noted that even though I am currently the most vocal, I'm not the only voice with this view.
The original lwa format is unreadable.
Really? You've written playback routines for LWA files that literally have a syntax encompassing less than a half dozen commands. I think you can tell as well as I can what's happening in the original file ;) .
I think it's apparent that a consensus on the matter probably won't be reached. So as much as I hate to say it, it looks like we might be needing to rely on conversion utilities for compatibility between applications. When you get right down to it, that's not a big deal. A conversion utility in the form of input and output filters would be a requirement internal to any app using XML anyway, so the end result will pretty much be the same.
RandyT
-
I think the best thing would be that Randy specifies the format he wants for his hardware. He impose the standard and that's it. We have just to follow. After all , it is his hardware.
No?
-
I think the best thing would be that Randy specifies the format he wants for his hardware. He impose the standard and that's it. We have just to follow. After all , it is his hardware.
No?
Ahhh ...Well if he was 'paying' for software development then yeah sure he would get the final call. :P
But I agree with Randy's point here so let's move on:
So as much as I hate to say it, it looks like we might be needing to rely on conversion utilities for compatibility between applications..
Youki said he would make one to convert to his format in any case
I will probably end up making a converter one day to convert MaLa hardware/PacDrive animations anyway, so the fact that there are different LWA formats are no big deal, just a shame.
-
Ideally Arzoo should make a Plug'in system for his animation tools.
It calls a Save function in a DLL passing as paremeter the animation script in the format he choosed , and it is up to Front End or plug'ins dev to provide the plugin to save in their own format.
-
I think the best thing would be that Randy specifies the format he wants for his hardware. He impose the standard and that's it. We have just to follow. After all , it is his hardware.
No?
No, I don't want to impose anything. But likewise, I have to do what I feel is the right thing for the things I do, which is no different from anyone else.when they create something, be it hardware, software, etc... This is why a standardized format probably isn't a good idea as everyone will have a different idea as to how they want to do things, as well as the feature set they plan to implement. The format really doesn't matter, as long as both a tool exists to create and edit animations and another exists to play them back using the same format. Just as you have already done by putting both tools into one package.
The format I created had it's reasons when it was done and those reasons are still valid. So far, no-one has been able to say why that format is no longer viable, only that they "like" something else better. In these matters of personal taste, there can never be consensus without concession and it's evident that there's not much interest in that :)
So I agree that the best way to approach things for those who want to support the hardware is to use whatever format they wish to internally and use, as you said, some type of "plug-in" system to provide compatibility with individual applications. The plug-ins can be written either by the FE developers or the Editor developers at their discretion. This approach also has the benefit of not imposing a limitation on the playback capabilities of a system based only on the capabilities of the editor, or imposing limitations on one editor based on the limitations of another.
RandyT
-
Randy, I'm sure this has been mentioned elsewhere, but I haven't seen it.
First, can we get a better idea of the system requirements? ie, hardware limitations, communication, etc. if they can be shared.
Second, what, exactly, are your goals that made you go with the current file format you have in place right now?
-
Randy, I'm sure this has been mentioned elsewhere, but I haven't seen it.
First, can we get a better idea of the system requirements? ie, hardware limitations, communication, etc. if they can be shared.
Second, what, exactly, are your goals that made you go with the current file format you have in place right now?
As one would expect, the main goal is to have the device work with any HID compatible system, so long as the communication software is available. The next is simplicity. I want anyone with even a rudimentary knowledge of VB to be able to develop for it.
But one of the big reasons for why the current LED-Wiz "language" looks like it does is so that the "resident" monitoring software can recognize the commands in the clipboard, and act upon them. This allows one to issue commands, to include the playback of animation files, from just about any application. Those commands remained constant for both manual / programmatic entry and in the animation files.
The WIP resident software still has the clipboard communication method (can be disabled), but also has a new method that looks for LED-Wiz commands in window captions. This is a much more reliable method that is just as simple for a programmer to access as the clipboard (probably more so.) While this may not be the method of choice given that there is an OCX and 2 DLLs available, there will be a couple of perks available when running the resident software. And for generic operation of the device, it is still valuable. Therefore, given my purposes, it is difficult for me to find justification to do away with the current format.
RandyT
-
I'll respect it if the following Q. is proprietary.
Is the chosen format a direct result of the communication with the controller? In other words, is the driver simply grabbing the text command and passing them on to the controller or is the driver repacking (or compiling it as it were) into some controller specific language?
-
I'll respect it if the following Q. is proprietary.
Is the chosen format a direct result of the communication with the controller? In other words, is the driver simply grabbing the text command and passing them on to the controller or is the driver repacking (or compiling it as it were) into some controller specific language?
There is a simple protocol, but the data format of the SBA and PBA commands is very similar to what is sent to the hardware, minus some padding. That's why the documentation for the OCX labels those commands as "Most Efficient" They require very little processing before being sent. Even though the parser accepts other commands for the sake of simplicity, SBA and PBA are always recommended for animations, and even then, they should only be sent when not redundant.
RandyT
-
I would never use the clipboard like that in any program. It is considered an irritation to the user. I think I remember a heated thread about it on here a little while ago so I don't want to go there again. But thats my opinion on the clipboard method you use.
Also, when you say you designed the format to make it easy for a VB6 programmer, what makes you think parsing xml is harder? With a library it's actually easier to parse than reading in a file line by line, splitting it up, converting it to integer values, then packing the bits into 8-bit bank numbers then sending them to the ocx or dll. The new format proposed is easier to parse for the beginner not harder.
I think programmers get in these mind sets about old formats and don't like changing to the new ones. They are the new format because they are better. All this drama about speed, filesize and all that dosn't really carry water with me. And it's not change for the sake of change.
If Randy had a decent animation editor to offer with the LEDWiz there would be no discussion about the format of lwa files. Or if he (God forbid) paid a programmer like arzoo to write the software. But there is no editor, so since arzoo is the pioneer of that we might as well design a new format. From memory Randy's animation editor was incomplete and doesn't read back lwa files?
I would like to know if anyone is using the software Randy offers on the GGG site? Or do people use the LEDWiz SDK MikeQ and I developed? That contains example source in 5 languages including VB6.
EDIT: Sorry I missed Randy's paragraph about changing to using Window captions. That is a much better way to do it. Check out how Mame's output system works or window messages (like WM_USER + x) that would work too I guess.
-
You should read that headkaze :
http://www.ibm.com/developerworks/xml/library/x-sbxml.html
-
You should read that headkaze :
http://www.ibm.com/developerworks/xml/library/x-sbxml.html
Interesting read. Does Grok translate in French?
:D
-
Interesting read. Does Grok translate in French?
:D
I think it translates something like "analyser afin de découvrir le sens " (analyse in order to discover the meaning) .. "essayer de comprendre" (try to understand).
-
Great article, Youki. Thanks for posting the link. It sums up quite accurately my thoughts on the matter.
I would never use the clipboard like that in any program. It is considered an irritation to the user. I think I remember a heated thread about it on here a little while ago so I don't want to go there again. But thats my opinion on the clipboard method you use.
Ok, we all get the idea that programmers neither need, nor like the clipboard method. Of course, none of the critics have been able to offer another method in which anyone, using virtually any program, can control the outputs of the LED-Wiz, or start the playback of an animation. The critics have, however, attempted to do things with it that it wasn't designed for, like brute forcing animations through that interface, only to further criticize it when it has difficulties. Many of my customers have used the clipboard interface and the comments from them relate to how convenient it is for simple control, not that it is "irritating".
Also, when you say you designed the format to make it easy for a VB6 programmer, what makes you think parsing xml is harder? With a library it's actually easier to parse than reading in a file line by line, splitting it up, converting it to integer values, then packing the bits into 8-bit bank numbers then sending them to the ocx or dll. The new format proposed is easier to parse for the beginner not harder.
First of all, one would need to learn how to use the library. There are millions of VB programmers and I'm not operating under the assumption that writing code that deals with XML is all of their "day jobs", or that it should be. Sure, if you deal with it on a regular basis, it's going to be easy for you. I look at assembly and think it is so simple anyone should be able to use it, but if that were the case there would be no high level languages like C and BASIC. It's all about what one is used to.
As for packing bits into 8-bit numbers, you'll need to do that anyway in order to use the hardware, so it's not part of the issue at hand. And anything you get back from the XML schema you showed will need to be equally massaged for the hardware...essentially into the current format!
I think programmers get in these mind sets about old formats and don't like changing to the new ones. They are the new format because they are better. All this drama about speed, filesize and all that dosn't really carry water with me. And it's not change for the sake of change.
And likewise, new programmers get wrapped up in "what they know, or simply theorize to be improvements" and tend to ignore the basic fundamentals which dictate selecting the right tool for the job. If it doesn't bring new capability to the table, it's simply re-packaging based on preference and that is "change for the sake of change".
If Randy had a decent animation editor to offer with the LEDWiz there would be no discussion about the format of lwa files. Or if he (God forbid) paid a programmer like arzoo to write the software. But there is no editor, so since arzoo is the pioneer of that we might as well design a new format. From memory Randy's animation editor was incomplete and doesn't read back lwa files?
Veiled insults aside, there is an editor, and while it does have it's problems, it allows one to easily create optimized animations. It was used to create the very first animation (http://www.groovygamegear.com/LEDWiz.mpg)ever witnessed by anyone when the hardware was still in testing phases, and has been used by virtually everyone since, until I think MikeQ and youki made theirs as part of their respective frontends (PowerMAME and AtomicFE.) However, if you choose to believe that this is the first time an editor has been written and that bestows some special consideration, then that's up to you. I've already stated that the best approach should be for each individual to do what makes the most sense for their applications and look at the plugin / Import / Export / Conversion utility examples. I plan to add just such functionality to my editor so that I, or any third party, can make a plug-in to allow simple exporting to anything they like. I'm not sure what more you would like me to do. But I can't do something I don't feel is in the best interests of the device simply because you want it to be that way.
I would like to know if anyone is using the software Randy offers on the GGG site? Or do people use the LEDWiz SDK MikeQ and I developed? That contains example source in 5 languages including VB6.
You can ask that question here, but you will not get an accurate picture of the needs of all users. The LED-Wiz is an output controller with enhanced PWM capabilities and pulse effects for lighting. Many of the people who find the current features useful don't come to this site, let alone this forum.
I missed Randy's paragraph about changing to using Window captions. That is a much better way to do it.
And I agree. I was quite impressed at the speed and low overhead of using this method. It didn't appear to have difficulties even when used to play very fast animations. Something the clipboard method was neither designed for, nor truly capable of (which is why there is an animation playback command with looping capabilities as part of the "official" LED-Wiz routines.) And that's why I will be offering it as an option.
RandyT
-
Another interresting Article about XML
http://www.xml.com/lpt/a/860
One line , i extracted from this article , that summarize well what i think
Don't turn off your critical faculties because something's a "standard"
it is exactly what seems to be happened to you Headkaze (lost of critical faculties) , when you write sentence like :
I think programmers get in these mind sets about old formats and don't like changing to the new ones. They are the new format because they are better
"New" does not mean "Better" (i know my english is not so good... but.. )
;)
-
I'm not going to bother bantering on with Randy about this anymore. It will end up turning into a flame war. If you actually read that artice (which is clearly an opinion piece) he is a big fan of xml. He just states that there are circumstances where xml dosn't suit. One example was a 1000 gig file. Most of them hardly apply here.
It's mainly the flexibility and scalability of the format I like. Arzoo can add more complex animation features to the format without it breaking parsers or making it even more unreadable than the current format is. That is my final word on the xml subject, I'm not going to debate it anymore.
Finally I believe Arzoo has already made up his mind on the better format, as I have. I know that me and Loadman will support him on that. That covers Mala and GameEx. Youki already has his own editor and his own format, that covers AtomicFE. Others like MameWah can use the LEDWizLighter command line util and LEDWizGen programs that me and Swindus developed.
Finally I think it's a good idea to create a universal LED animation format. Afterall Ultimarc is coming out with a new device which I will be adding to my plugin soon. Mala already supports it. Who's to say Andy won't be releasing an RGB LED controller some time soon? We should have a format that will support all devices that come out in the future, not just the LEDWiz.
-
I'm not going to bother bantering on with Randy about this anymore. It will end up turning into a flame war. If you actually read that artice (which is clearly an opinion piece) he is a big fan of xml. He just states that there are circumstances where xml dosn't suit. One example was a 1000 gig file. Most of them hardly apply here.
Of course, there are several items mentioned in that same article, making the case for not using XML, that do apply here. I can list them if you would like.
Afterall Ultimarc is coming out with a new device which I will be adding to my plugin soon. Mala already supports it. Who's to say Andy won't be releasing an RGB LED controller some time soon? We should have a format that will support all devices that come out in the future, not just the LEDWiz.
If this is what was motivating your viewpoints, It probably would have been beneficial to the participants in the discussion if you had stated it somewhere before now (like your first post in the thread.) It's difficult for other individuals to respond properly, or decide whether it was appropriate to respond at all, when "all the cards aren't on the table" and the topic of discussion appeared to be related to something else.
RandyT
-
Of course, there are several items mentioned in that same article, making the case for not using XML, that do apply here. I can list them if you would like.
I did read the article and I already said I don't want to keep this argument about xml ongoing. Just the simple introduction of a looping part for animations is enough to change the format IMHO. Or we could keep tacking on new things to the existing format like line numbers and a new GOTO command (and thus breaking every parser written already now anyway).
If this is what was motivating your viewpoints, It probably would have been beneficial to the participants in the discussion if you had stated it somewhere before now (like your first post in the thread.) It's difficult for other individuals to respond properly, or decide whether it was appropriate to respond at all, when "all the cards aren't on the table" and the topic of discussion appeared to be related to something else.
This is my hobby and I don't think that way. Don't get me wrong I'm not saying you don't have the same passion as I do, it's apparent you do. I just enjoy programming for this hobby so my interests lie in that. The format has made serveral changes over the course of the thread, and I never had the idea of making it universal until the last post I made. It's just another idea I'm throwing into the mix, I don't have the last word on anything in here.
These are my thoughts as they come to me, I am not giving you my "poker face" and introducing ideas I've already thought about. I really like your hardware and forked out a decent amount of money for my LEDWiz kit. I'm very happy with it, so don't think for one second I don't appreciate what you do for this hobby. Is that a "thiny vieled" thankyou? I hope not! Just incase "thankyou"! :)
Again, if were not careful this will become a flame thread. Lets try and keep to the topic and not get personal about ideas. These are just ideas and opinions afterall.
One last note to end this rant. I have no loyalty to a hardware manufacturer in this hobby, I support them all. Afterall wasn't it you who said in an e-mail to me that "competition is good for the scene"? ;D
-
Afterall wasn't it you who said in an e-mail to me that "competition is good for the scene"?
I think it is me who said that in a e-mail to you.
-
Afterall wasn't it you who said in an e-mail to me that "competition is good for the scene"?
I think it is me who said that in a e-mail to you.
No, I'm aware you said that but Randy did say the same thing to me in an e-mail.
To quote:
I see good things coming from competition between developers. It's how innovation happens.
Maybe he just meant software developers not hardware developers? :o
-
I see good things coming from competition between developers. It's how innovation happens.
Maybe he just meant software developers not hardware developers? :o
This is not the place to discuss my thoughts on competition, especially as innovation is concerned. But I appreciate your appreciation :)
Oh, and remind me to be careful of what I say to you in email. ;)
.RandyT
-
"Competition is good as long as they don't compete with me" :)
This is not the place to discuss my thoughts on competition, especially as innovation is concerned. But I appreciate your appreciation :)
Oh, and remind me to be careful of what I say to you in email. ;)
I purposly put your quote out of context to make an amusing parallel. I thought you would have got a laugh out of the irony; obviously competition for a business is more serious than a bunch of hobbiest programmers. Sorry I didn't think quoting you would offend. I just checked my e-mail to see if you said it, and just pasted the line to prove it. It wasn't meant to invade your privacy (won't happen again).
-
Since it appears we don't have consensus on the animation file format, I've decided to use a different file extension for the xml format; .lwax
-
Since it appears we don't have consensus on the animation file format, I've decided to use a different file extension for the xml format; .lwax
Wouldn't it be better to use the extension .xml? That way you can open it in an editor with syntax hilighting and the extension will be recognised.
-
Wouldn't it be better to use the extension .xml? That way you can open it in an editor with syntax hilighting and the extension will be recognised.
I think I'd rather distinguish it as a led animation file rather than just a generic xml file. You can always configure Windows to open the file with your xml editor of choice.
-
Wouldn't it be better to use the extension .xml? That way you can open it in an editor with syntax hilighting and the extension will be recognised.
I think I'd rather distinguish it as a led animation file rather than just a generic xml file. You can always configure Windows to open the file with your xml editor of choice.
Okay lwax is fine with me. I just knocked together a quick converter that has all those lwa's converted to lwax's. It can also convert back from lwax to lwa. Might be handy to run through your animation software for testing, although I suppose yours will import lwa anyway. If you see any bugs or errors in the format/program, let me know.
-
Thanks headkaze, I'll check out your conversion app tonight. I've updated LEDBlinky to use the new format (it can still read the old format). Now I can get back to working on the editor. :)
-
Thanks headkaze, I'll check out your conversion app tonight. I've updated LEDBlinky to use the new format (it can still read the old format). Now I can get back to working on the editor. :)
:notworthy: