RandyT

Understand that the solution may not be "one size fits all" for any hardware being used. I need to do some more evaluation of the code used in the script and the tables, but essentially, we know that the script overhead is what is very likely the root of the problem. This comes from the need to do data management and compilation for transmission to the hardware, or at least to whatever code is responsible for communication. The more work which can be handled externally, and the less which needs to be done by the script, the better things are likely to be in the end. All activity needs to be event driven, and communication intervals managed by external code to provide the best performance, using the least amount of overhead possible from within the VP scripts. I suspect that this will require a major overhaul to the current script, and certainly to the communication handler, as the methodology will be different. One unpleasant possibility is that the issue is caused simply by the script calling any outside procedure. If this is the case, then no amount of optimization using these methods will yield much improvement. I've stated before (perhaps it was on one of the FP forums) that the ideal approach would be to use low level hooks into the code to fire external events based on the firing of internal events. This would also need to run in a separate thread, or even a separate core. However knowing this, and being able to do it, are something quite different.

People shouldn't take my silence as "not caring" about the needs of users on this board. I spent quite a bit of time conclusively determining that the stutter folks have been attributing to the LED-Wiz, is in fact caused by the additional overhead of the scripting necessary to make external hardware work, and not the LED-Wiz or the supporting OCX. I think it's safe to say that this has been confirmed, as I expected, by the third point of PixelMagic's post above. I have also communicated on a number of occasions with the script authors to provide them with information to improve the script for use with the LED-Wiz, and those improvements were equally beneficial for other hardware it may support in the future. There is another approach I have been formulating, but this would need the help of the script writers, as it would likely require a major rewrite of their code. The reason the "stutter" issue hasn't been fixed by me is because it's not a hardware issue. It's the load from the extra VP scripting which doesn't need to be executed when no external hardware is being used. RandyT

Interesting. It seems that some type of delay is still necessary with the OHCI chipsets (which I am pretty sure is the one on your system at this point). UHCI controllers (Intel and VIA chipsets) should work with the FastCom property set to true. The OCX and the use of the sleep api is still what I believe is causing the "stutter" issue. The LED-Wiz is used primarily with a DLL in other applications, and slowdown has never been an issue. I'm not sure how compatible DLLs are with VBScript. I'm pretty sure I can use an alternate method of delaying the output (only 1 or 2 milliseconds is necessary) and will compile a new OCX with this other method. As I cannot test for this myself, I will need a volunteer to try the new OCX and let me know the results. If you are interested, please email me and we can see if this can be remedied. I'd rather not continue to de-rail this particular thread, so if there is a better place to continue the discussion, we should probably move it there. *edit* Please continue discussion -> here

This is the chipset issue I was referring to. How old is the LED-Wiz? I still encourage others to try making the change above to see what happens on their systems..

While I don't wish to inject into a thread for a different product, this seems the most appropriate place, considering the title of the thread and the reasons being discussed. I have seen numerous complaints here about "stuttering" or pauses on machines where the LED-Wiz is being used. So, I started looking through the ledcontrol.vbs code, and found that a very inefficient OCX command was being used to set the PWM levels in ways it was never designed to be used. Through discussions with the authors, I believe this has been remedied. But there is still one glaring omission that may be responsible for some of what folks are seeing. The LED-Wiz requires a short (1-2ms) delay between communications with certain USB chipsets, so when the OCX (the code the ledcontrol.vbs is calling) was written, it defaulted to a compatible mode which inserted a short delay to make sure that the hardware had time to process the previous set of instructions. The method of the delay used was the sleep API. Microsoft states that the sleep API delays updates to graphics redraws which occur within the same thread. When this is called many times in succession, as is the case when multiple events occur in a short period of time, the lack of screen updates would be apparent to the player. To me, this sounds like the cuplrit, as what is being described as "stutter" is the lack of graphic updates when the LED-Wiz is being communicated with, over and over, within a short time frame. The most likely solution, or at least the first thing to try: In the LED-Wiz OCX, there is a property which can be set to disable this delay. This would be the FastCom property, and it should be set to true. So those of you experiencing a lack of screen updates when using the LED-Wiz should try the following to see if it helps; Get the latest version of ledcontrol.vbs on your system and find the following piece of code Public Sub ResetLedWiz() LedControl.Command ="PBA: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,48,48,48" End Sub and change it so it looks like; Public Sub ResetLedWiz() LedControl.FastCom=True LedControl.Command ="PBA: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,48,48,48" End Sub If you have a specific USB chipset (OHCI-based), your setup might have a problem with this. But all UHCI-based USB chipsets (Intel, VIA) should deal with this just fine. If it does, in fact, cure the graphic update issues, you should also scale back the interval setting which controls how often the script communicates with the hardware. It may be that delays will no longer be necessary. To Moderators: Please accept my apologies if this post is not where it should be, and feel free to move it somewhere more appropriate if this is the case. It seemed appropriate to post a possible fix to issues being described where the hardware was being blamed for what seems primarily to be software implementation issues . RandyT