Main > Software Forum
LED Animation Editor - question for all the LED-Wiz Devs...
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:
--- Quote from: youki on July 24, 2007, 05:49:37 am ---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?
--- End quote ---
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:
--- Quote from: SavannahLion on July 24, 2007, 01:56:18 pm ---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?
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version