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

[arzoo]

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]

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!

[RandyT]

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

[rockin_rick]

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

[arzoo]

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

[RandyT]

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

[headkaze]

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

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.

Code: [Select]

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


[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

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

[youki]

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? 

[loadman]

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. 

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.

[youki]

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.

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

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

[SavannahLion]

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?

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

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

[SavannahLion]

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?

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

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

[headkaze]

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.

[youki]

You should read that headkaze :

http://www.ibm.com/developerworks/xml/library/x-sbxml.html

[Havok]

You should read that headkaze :

http://www.ibm.com/developerworks/xml/library/x-sbxml.html

Interesting read. Does Grok translate in French?

 

[youki]

Interesting read. Does Grok translate in French?

 

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

[RandyT]

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

[youki]

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

 

[headkaze]

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.

[RandyT]

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

[headkaze]

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

[youki]

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.

[headkaze]

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? 

[RandyT]

I see good things coming from competition between developers.  It's how innovation happens.

Maybe he just meant software developers not hardware developers? 

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

[headkaze]

"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).

[arzoo]

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

[headkaze]

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.

[arzoo]

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.

[headkaze]

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.

[arzoo]

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. 

[loadman]

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.