Main > Software Forum
If you would like to build multi LED-Wiz support into your software...
Howard_Casto:
No the thing is, you are full of yourself or something and don't listen to what I'm saying anyway so I'm tried of trying to get you to listen. Going down the list again and restateing the things that you either ignored or answered in a way that still doesn't address the point I brought up is useless.
But for one final attempt I'll re-address a single issue once more an maybe, just maybe you'll listen this time.
Your wrote:
"Here again you call something a flaw without understanding why it was done this way (and you wonder why I might think you are trying to be negative or get on my nerves ). State commands take only 1 USB packet, whereas Profile data takes 4. If you really want to do fast manipulations, you set up the profile information first and animate with the state controls. If you want to do the whole shebang with the Profile commands, be my guest. It won't be nearly as efficient or as fast for simple on/off style animations, but there's nothing stopping you from doing it that way."
If doesn't matter that profiles are slower because if you are using rgb leds you HAVE to send both commands. Let me repeat that again.... if you are using rgb leds you HAVE to send both commands.
I think I stated that it was a good option to do it seperately but you shouldn't require it.
First you have to turn on a light and then you have to set it intensity or vice versa to get the appropriate color, two commands that you have to send for even the simplest of programs that use rgb leds.
You keep throwing around the term "rapid succession," saying that with normal use this isn't an issue. If you call turning on the lights once rapid succession once then I guess what you say is correct, but otherwise it isn't as any application will have to send two commands, one after another or deal with all the timing/error issues if they are using the clipboard. I'm not trying to do animation at all with the clipboard, I just attempted to light a frikkin light with the correct intensity and have it light every time.
Regardless of that, as we've already established you have to send both commands to the device if you are dealing with rgb leds. Keeping that in mind if you ever had any inention of supporting rgb's when you designed the thing (and I have a feeling you did) it would have made more sense to also be able to turn on and off the leds via profile as 4 packets are smaller than 5.
And sure you can light the lights once with the sba command and then just adjust the intensity to change the states as you said but I wouldn't reccomend it. You see your resident app crashes if you try to adjust a light with it that has an intensity set to 0. Just thought you might like to know.
You also said that I'm only looking at things from my perspective. I take extreme offense to that. Think about it, you've given me an ocx and it works for what I need it for so from my perspective I'm done and don't need anything further. I'm looking out for everyone else.
I'm also aware that you programmed the chips which makes me wonder why you don't just document it and release that. Then we wouldn't have to deal with any of this and just use our own method of interface. Yes I'm aware that direct interface with HID device isn't exactly a walk in the park to beginners but it would be another option to us.
Btw... I think something might be off with the mult-device ocx. It seems slower than the other and when you kill any application that is using it, it turns all the lights off, this would be bad for a app that simply sets the lights and closes itself. It works for my purposes but contrary to popular belief I am looking out for others interests and telling you anyway.
RandyT:
--- Quote from: Howard_Casto on July 29, 2006, 01:11:48 am ---No the thing is, you are full of yourself or something and don't listen to what I'm saying anyway so I'm tried of trying to get you to listen.
--- End quote ---
That goes both ways, Howard.
--- Quote ---Your wrote:
"Here again you call something a flaw without understanding why it was done this way (and you wonder why I might think you are trying to be negative or get on my nerves ). State commands take only 1 USB packet, whereas Profile data takes 4. If you really want to do fast manipulations, you set up the profile information first and animate with the state controls. If you want to do the whole shebang with the Profile commands, be my guest. It won't be nearly as efficient or as fast for simple on/off style animations, but there's nothing stopping you from doing it that way."
If doesn't matter that profiles are slower because if you are using rgb leds you HAVE to send both commands. Let me repeat that again.... if you are using rgb leds you HAVE to send both commands.
--- End quote ---
You can repeat it as many times as you want, Howard, it's just not true. You can do on / off animations (sweep, chase, twinkle, etc) with RGB LED's just fine with only the state commands.
If you want to set up a specific color, that must be done first, but only one time. Otherwise just use the defaults and live with the 8 possibilities created by the default profile of the RGB LED (full-on) and just use the state commands.
If you are color morphing or using non-hardware pulse effects, you obviously need to use the profile commands in conjunction with (Or instead of) the state commands.
--- Quote ---I think I stated that it was a good option to do it seperately but you shouldn't require it.
--- End quote ---
And, as I stated, It is not required.
--- Quote ---First you have to turn on a light and then you have to set it intensity or vice versa to get the appropriate color, two commands that you have to send for even the simplest of programs that use rgb leds.
--- End quote ---
The intensity defaults to 48 for all outputs. If you are happy with one of the 7 color possibilities provided by the default, then you do not need to use the profile command at all.
But if you do, you need use it only once at the start of the program. Or, you can do this:
Use the control to send the PBA:0,0,0,.......,0 command. Then send an SBA:255,255,255,255,5 command. From that moment on, as long as your program is running, you will need only to use the Profile commands. Just set the profile of the output to 0 to turn them off.
--- Quote ---You keep throwing around the term "rapid succession," saying that with normal use this isn't an issue. If you call turning on the lights once rapid succession once then I guess what you say is correct, but otherwise it isn't as any application will have to send two commands, one after another or deal with all the timing/error issues if they are using the clipboard. I'm not trying to do animation at all with the clipboard, I just attempted to light a frikkin light with the correct intensity and have it light every time.
--- End quote ---
And as I stated earlier, if you overwrite the clipboard before the resident app is able to retrieve the data, you will lose commands. This is a developer, not an end-user concern. Developers are made aware of these mechanisms. An end-user is incapable of creating this condition manually, or with any tool provided.
--- Quote ---Regardless of that, as we've already established you have to send both commands to the device if you are dealing with rgb leds. Keeping that in mind if you ever had any inention of supporting rgb's when you designed the thing (and I have a feeling you did) it would have made more sense to also be able to turn on and off the leds via profile as 4 packets are smaller than 5.
--- End quote ---
No, this has not been established.
--- Quote ---And sure you can light the lights once with the sba command and then just adjust the intensity to change the states as you said but I wouldn't reccomend it. You see your resident app crashes if you try to adjust a light with it that has an intensity set to 0. Just thought you might like to know.
--- End quote ---
:notworthy: Congratulations, you found a bug in the beta animation editor. How does this affect an external program setting the profile to 0 to shut off an output, which is perfectly valid and works just fine?
--- Quote ---You also said that I'm only looking at things from my perspective. I take extreme offense to that. Think about it, you've given me an ocx and it works for what I need it for so from my perspective I'm done and don't need anything further. I'm looking out for everyone else.
--- End quote ---
We did this dance in the past as well, Howard. Long before you had an actual unit to play with. If you aren't operating from an agenda, it's difficult to see it that way based on your past comments. Kind of like a "self-fulfilling prophecy", if you know what I mean.
--- Quote ---I'm also aware that you programmed the chips which makes me wonder why you don't just document it and release that. Then we wouldn't have to deal with any of this and just use our own method of interface. Yes I'm aware that direct interface with HID device isn't exactly a walk in the park to beginners but it would be another option to us.
--- End quote ---
The answer is simple. It's a commercial product. It's not shareware nor covered by the GNU license. Ask the guys over at CodeWarriors to document everything for you and see how far you get with them.
--- Quote ---Btw... I think something might be off with the mult-device ocx. It seems slower than the other and when you kill any application that is using it, it turns all the lights off, this would be bad for a app that simply sets the lights and closes itself. It works for my purposes but contrary to popular belief I am looking out for others interests and telling you anyway.
--- End quote ---
1)It's possible that it is slightly slower. Between-packet throttling has been implemented to fix a possible packet loss issue that manifested itself with certain USB chipsets (see the PowerMAME board) Reliability is more important than speed (and it is already plenty fast)
2) The app doesn't shut down the device, rather Windows resets it when shutting down the app from within the VB development environment. Compiled applications running outside of the development environment do not exhibit this behavior.
RandyT
Space Fractal:
us, that dosent use VB would still been easier to use a a dll. Im would still not been happy, if clipboard is overtaken by a application (Im known it NOT a issue in a cab, wich this software was writting for).
A Another thing is, what about to use a window caption instead of clip folder (wich I also really dislike)? It simple to use utility like Autohotkey to change a caption, and reviewed by the software. The window is of course hidden (or shown by debugging), but it can been found by AutoHotKey.
Autohotkey is used by many and mosly all wrappers is wrote in this utility (do I take fool Howard?).
youki:
--- Quote ---us, that dosent use VB would still been easier to use a a dll.
--- End quote ---
You can use OCX from almost every existing windows language , VB , Delphi, Visual C++ , Windev , Power Builder, and almost all other windows compiler , and even from script language like VScript, JScript...
OCX , is no more that a kind of DLL . Just based on COM technology. I don't know any "relativly" modern language for windows (from after 1995) that does not support Ocx.
I would like test that things.. but i don't have ledwiz... :'( Randy did you read my mail?
RandyT:
--- Quote from: youki on July 29, 2006, 10:06:03 am ---
--- Quote ---us, that dosent use VB would still been easier to use a a dll.
--- End quote ---
You can use OCX from almost every existing windows language , VB , Delphi, Visual C++ , Windev , Power Builder, and almost all other windows compiler , and even from script language like VScript, JScript...
OCX , is no more that a kind of DLL . Just based on COM technology. I don't know any "relativly" modern language for windows (from after 1995) that does not support Ocx.
--- End quote ---
Thanks for your input on the OCX compatibility issue. That's good info to know.
--- Quote ---I would like test that things.. but i don't have ledwiz... :'( Randy did you read my mail?
--- End quote ---
Yes, and I responded. I was wondering why I hadn't heard back from you! I'll send off my response again. If you don't get it, pm me here.
RandyT
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version