Main > Software Forum

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

<< < (9/15) > >>

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:

--- Quote ---Youki - I think the frame is also necessary as it is/can be used as a label allowing goto's back into the animation.
--- End quote ---

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:

--- Quote from: arzoo on July 23, 2007, 02:03:29 pm ---Syntax errors should be captured by the xml library when the file is loaded. Misspelled commands would cause problems no matter what the format.

--- End quote ---

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.


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

--- End quote ---

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.


--- Quote ---If the new format (or old for that matter) causes any problems with streaming data directly from files, it would be the disk I/O that's causing the delay. Not the data parsing.

--- End quote ---

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.


--- Quote ---I have no doubt - you always sweat the details. Your hardware has advanced this hobby to a new level. As has all the incredible software developed by the community!

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version