If you would like to build multi LED-Wiz support into your software...

[RandyT]

See this thread.

Thanks,
RandyT

[RandyT]

^{*Cross posted - Mods feel free to delete whichever is felt to be inappropriate*}

Whew, this took longer than anticipated.  Decided to add a couple of extra commands and make some proper documentation.

The documentation can be viewed by clicking here (Acrobat Reader required)

The package has been sent to those who first requested it.  If I missed anyone, please let me know.

BTW, the license agreement is basically boiler plate to protect against malicious use of the hardware/software.  Anyone in  this community who wishes to use / re-distribute the control as part of their application(s) can pretty much consider it "rubber stamped" as approved.

Thanks,
RandyT

[Howard_Casto]

Looks good thanks..... Something that seems absent from your ocx is the ability to read states as well as write them.  Since it's faster to set all the states and intensities at once, it would be nice if you could check to see if any other programs have messed with the lights and use those vlaues on any lights that are on.  A good example of this would be a keyboard hook to link the mame coin lights (keyboard leds) to buttons.  Now obviously you just turn those three on individually, but if there is another program doing something with the rest of your lights in the background, you want to be able to keep it from interfering with the coin lights. 


Btw.... I know you'll get mad when I say this, but you really need to stop pushing the clipboard method and start pushing the ocx.  Since I've been so negative about the option I wanted to be fair, so that was the first thing I tried when I got the product.  To be blunt it doesn't work.  First you have to turn on a light with one command, and the you have to set the intensity right?  Well if you send two commands without delay, only the last command takes.  You have to set a fairly huge dealy of 200ms for it to take in a reliable fashion. That is if you are using the command line tool.  If you use direct access to the clipboard it doesn't work at all.  I looked up the issue at msdn and it said if two seperate programs try to access the clipboard at the exact same time they both error out and neither command gets accepted.  Since the ledwiz resident app constantly gets the text of the keyboard and whatever app is communicating is constantly setting the text of the clipboard it only stands to reason that eventually the two will hit each other and error out.  It might just be unique to my system, but it errored out farily regularly for me, making it unstable.  Spent two days messing with the clipboard method and never got it to work reliably. 


Now in contrast, I downloaded the ocx from the ledwiz thread.  Had it up and running in 10 minutes and I can get a 3 ms response time for commands, which is more than acceptable.  Been getting it to do all kinds of crazy things since then, that nobody has thought of yet, I'll release a demo of the goofy stuff I'm getting it to do later. 


Anyway, my point is the hardware is very good, but the clipboard method doesn't make things easier, rather it makes things harder.  The ocx is very easy for anyone using a visual studio language to use and it works very well... for that matter your device shows up as HID so if you released some specs about the data transmission, we could access it directly.  Just a thought.  My suggestion for you is to ditch the command line tool you currently include and make a new one the uses the ocx rather than the clipboard.  This way even the non-visual studio programmers have something fairly quick and easy to use. 


Thanks for the work on the new ocx....Once J5 has ledwiz support fully implemented I'll hand it over to my minions and see how it works for them. 

[RandyT]

Looks good thanks..... Something that seems absent from your ocx is the ability to read states as well as write them.  Since it's faster to set all the states and intensities at once, it would be nice if you could check to see if any other programs have messed with the lights and use those vlaues on any lights that are on.  A good example of this would be a keyboard hook to link the mame coin lights (keyboard leds) to buttons.  Now obviously you just turn those three on individually, but if there is another program doing something with the rest of your lights in the background, you want to be able to keep it from interfering with the coin lights. 

You are welcome.  But I don't think I'll be able to provide what you are asking for.  The parser tracks all of the settings of the outputs, but I'm not sure how I might go about making that info available to another program using a completely different instance of the control.  It would probably make more sense to add the keyboard LED emulation code to the OCX and allow developers to decide whether to use it or not. 

Btw.... I know you'll get mad when I say this, but you really need to stop pushing the clipboard method and start pushing the ocx.  Since I've been so negative about the option I wanted to be fair, so that was the first thing I tried when I got the product.  To be blunt it doesn't work.  First you have to turn on a light with one command, and the you have to set the intensity right?  Well if you send two commands without delay, only the last command takes.  You have to set a fairly huge dealy of 200ms for it to take in a reliable fashion. That is if you are using the command line tool.  If you use direct access to the clipboard it doesn't work at all.  I looked up the issue at msdn and it said if two seperate programs try to access the clipboard at the exact same time they both error out and neither command gets accepted.  Since the ledwiz resident app constantly gets the text of the keyboard and whatever app is communicating is constantly setting the text of the clipboard it only stands to reason that eventually the two will hit each other and error out.  It might just be unique to my system, but it errored out farily regularly for me, making it unstable.  Spent two days messing with the clipboard method and never got it to work reliably. 

Howard, you should really listen and try to understand my stance on this 

1: There was no ActiveX control when the LED-Wiz was first released.  I didn't even know how to write one at that time.

2: Not everyone can use an ActiveX control.

3: Not everyone can program, but can probably write a command line for an application in order to turn on some lights.

4: The clipboard method was provided as a means for a user to "hit the go button" for playback of animations they created with the editor.  It was never intended to be the mechanism that actually did the work of playing them.   The clipboard is only polled 10 times a second by the resident software.

5: To reliably use the clipboard method for relatively fast manipulation of the outputs, one has to use error checking when accessing the clipboard.  You are right that 2 applications attempting to write to the clipboard will cancel each other out, but that act raises an error condition that can be trapped.  In that event, the software should simply re-try.  To my knowledge, reading from the clipboard has no such problems.  You also need to have your application watch the clipboard and not attempt to send another command to it until the previous one has been cleared by the resident software.  It's a very rudimentary protocol, but it needs to be followed closely if you intend to push the limits.  I know It works, as I tested it rather completely before ever releasing it.  I ran into the same problems you described and I overcame them.  It's how I know the information above.  Others have also been able to use it effectively.

6: I am not now, nor have I ever "pushed" the use of the clipboard method over the more direct capabilities offered by the ActiveX control.  It would be stupid to do so.  But, the clipboard method does have advantages.  It offers non-programmers or programmers who do not use the "visual studio" languages a means to control the hardware where otherwise, no method would exist.  I've also never stated that it was "easier" to use the clipboard method.  But one thing I will tell you; if it's your only option, it's easier than buying and learning a visual studio language just to turn on a few lights!

My suggestion for you is to ditch the command line tool you currently include and make a new one the uses the ocx rather than the clipboard.  This way even the non-visual studio programmers have something fairly quick and easy to use. 

The problem with this is that the control scans for the presence of 16 LED-Wiz devices at startup and initializes the ones it finds.  This causes a very short, but nonetheless noticeable delay at first run.  If it is just left running in the background, you still need to talk to it somehow, and that method would need to be universally available (like the clipboard is).  If you have suggestions for how this mechanism should work, please forward it to me and I will look into implementing it.

Thanks for the work on the new ocx....Once J5 has ledwiz support fully implemented I'll hand it over to my minions and see how it works for them. 

No problem.  I can't wait to see what everyone does with it.

RandyT

[Space Fractal]

Why not to use a dll instead of clipboard?

Personly I have allways used dll

[Howard_Casto]

On the responses......

I agree SF, actually I'm a vb programmer and I find active x plugins to be rather dumb, but they are easier to write (I thought that might be the issue and randy has confirmed it) and one is available. 

And Randy the issues are there with the clipboard method.  I tried in a few languages and couldn't get a reliable clipboard interface to work in any of them.  I could get it to work, just not in a way that I could depend on 100% of the time.  The checking to see if your app has cleared the clipboard thing is nice to know and probably woudl have helped, but you don't mention it anywhere.  About as much as you mention regarding the clipboard method is that you can use the command line app and you simply write the command to the clipboard to set the lights.  If you want people to use this method you need to better explain how, because your device is literally the only one that uses constant clipboard monitoring to do stuff.

You might not realize it, but you do push the resident app and not the ocx.  To find the original ocx I had to search through a two year thread buried on this forum and download it from there (optionally I could have emailed you, but you were busy making the new one so I didn't bother).  On the other hand the resident app is available on your site in a zip and is mentioned on the ledwiz docs as being "a zip file containing all led wiz related software."  The ocx isn't mentioned anywhere, not even on your own site.  If I hadn't been involved in the orignal thread and remembered you mentioning it, I would have never known it existed. 

And I totally understand that originally you didn't have access to this, but now you do, and you can make new default apps which get away from the clipboard using a new command line inteface app that uses the ocx instead of the clipboard... so go do that! 


oh and point #3, it's not valid....

Your telling me that writing:
shell "lwsend.exe LWSBA:255,255,255,255" is harder than :

temptext="null"
do util temptext=""
     temptext=clipboard.gettext
loop
clipboard.clear
clipboard.settext "LWSBA:255,255,255,255"

Every language has an equivelent of a "shell" command and it's always easy to use and doesn't require any special setup.  On the other hand not every langauge has immediate access to the clipboard.  In the case of vb and visual c it's easy, but with some you have to use a api call, which is definately an advanced issue.  And yes, you include a command line app with the default software, but it's clipboard-based, meaning that the resident app has to be loaded (making the code even more complicated and wasting memory) and you still can't send two commands in rapid succession, meaning that this method also doesn't work unless you use "shellandwait" which is infinately more complicated than regular old shell. 
Just wanted to put things in perspective for ya.

You seem to think I'm trying to be negative or just get on your nerves, I'm not.  I like the product, it works well and it's cheap, but the software doesnt work well and you have a stance of defending the software rather than trying to implement some of the suggestions is hurting the accessability of the product and probably the sales of the product.  I could even see official support for the device being put into mame one day, but not if it has to rely on external means to interface with it. 

You defend the clipboard method as being for non-programmers and I tend to agree when it comes to a user just wanting to change the color of their lights or load a animation and that's it by writing the command in a text file and copying it, but considering how much work has to be done to get the clipboard to work correctly compared to just having a dll, command line inteface/active x/ect that uses the exact same commands and looks exactly the same but "just works" it seems like non-programmers that are writing their first little app are still going to find it easier to use something easier than the clipboard. 

The flaw really lies in the command structure if you ask me.  It takes two commands to light a light (or bank of lights ect) instead of one. One command to turn the light on and another to set the intensity, instead of having the device automatically turn the light off when you set the intensity to 0 and automatically turn it on when you set the intensity great than 0.  Being able to set the intensity before lighting a light is definately a good idea as an option, because I can see real uses for it, but not as a requirement. 

These are just suggestions, if you don't want to use em fine, but when something doesn't work well for me and I (sorta) know what I'm doing then it stands to reason that others will have similar issues.  Of course, that I know of maybe only 4 people are writing stuff for the ledwiz, myself included.  It might be related. 

We're not out to get ya man, we are here to help. 

[RandyT]

I agree SF, actually I'm a vb programmer and I find active x plugins to be rather dumb, but they are easier to write (I thought that might be the issue and randy has confirmed it) and one is available. 

Then you must also know what nightmare it is to write a real DLL (not an ActiveX one) from VB and that it was not intended to be done from that development platform.  No point in hashing that one out, though.  MikeQ will probably make his DLL "VB Friendly" so you can use it,  if you find ActiveX controls to be too "dumb" for your tastes. 

And Randy the issues are there with the clipboard method.  I tried in a few languages and couldn't get a reliable clipboard interface to work in any of them.  I could get it to work, just not in a way that I could depend on 100% of the time. 

Not sure what to tell you on that one, Howard.  I've done it, as have others.  If I couldn't make it work reliably, I would have never released it this way.

The checking to see if your app has cleared the clipboard thing is nice to know and probably woudl have helped, but you don't mention it anywhere.  About as much as you mention regarding the clipboard method is that you can use the command line app and you simply write the command to the clipboard to set the lights.  If you want people to use this method you need to better explain how, because your device is literally the only one that uses constant clipboard monitoring to do stuff.

 

I don't want people to use the clipboard method that way, but I can't stop them.  Using the clipboard method for fast, direct manipulation of the outputs really isn't recommended.  Creating an animation with the editor and telling the resident software to play/loop it, or changing the color/state of your buttons, is.  Unless you are attempting to push beyond the limits of the interface, that little tidbit is of no use to you. 

Howard, you are viewing the resident software as something that it is not, and was never designed to be.  The resident software was designed to offer MAME compatibility via Keyboard LED emulation (which it does better than any keyboard encoder due to the configurability and wider selection of devices that can be connected directly), provide playback of animations created with the built in editor and to provide a reasonable universal interface for basic control.   The LWSend program provided is a means for a non-programmer to control the outputs via a command line interface.  The program executes, sends the command (via the clipboard) and exits.  It's not intended to be called a gazillion times consecutively in an attempt to do animation with it!

You are "complaining about poor acceleration with your Geo because you chose to cut the floorboards out and are pushing with your feet."

You might not realize it, but you do push the resident app and not the ocx.  To find the original ocx I had to search through a two year thread buried on this forum and download it from there (optionally I could have emailed you, but you were busy making the new one so I didn't bother).  On the other hand the resident app is available on your site in a zip and is mentioned on the ledwiz docs as being "a zip file containing all led wiz related software."  The ocx isn't mentioned anywhere, not even on your own site.  If I hadn't been involved in the orignal thread and remembered you mentioning it, I would have never known it existed. 

Developers email me.  They do it all the time.  The OCX was indeed mentioned on the site, specifically in the paragraph that stated the fact that our OCX did not (like it does now) support multiple devices.  I do NOT push the resident app to developers.  I tell them what options are available and where to get them.  The clipboard method is always the route of last resort.  If you had bothered to email me and ask, you would have received the same response.  And before you say it, yes, you have to ask for development tools.  They aren't intended for consumption by the same audience as the resident app.

And I totally understand that originally you didn't have access to this, but now you do, and you can make new default apps which get away from the clipboard using a new command line inteface app that uses the ocx instead of the clipboard... so go do that! 

 

Geez, Howard, I never needed access to an OCX or DLL.  I wrote the native communication routines!  You completely missed the point I was trying to get across to you about the need for one application to be able to talk to another somehow.  As I stated before, if you have a suggestion here, please bring it forward!

oh and point #3, it's not valid....

Your telling me that writing:
shell "lwsend.exe LWSBA:255,255,255,255" is harder than :

temptext="null"
do util temptext=""
     temptext=clipboard.gettext
loop
clipboard.clear
clipboard.settext "LWSBA:255,255,255,255"

No, actually I said just the opposite.  So it seems we are in agreement on that one.

Every language has an equivelent of a "shell" command and it's always easy to use and doesn't require any special setup.  On the other hand not every langauge has immediate access to the clipboard.  In the case of vb and visual c it's easy, but with some you have to use a api call, which is definately an advanced issue.  And yes, you include a command line app with the default software, but it's clipboard-based, meaning that the resident app has to be loaded (making the code even more complicated and wasting memory) and you still can't send two commands in rapid succession, meaning that this method also doesn't work unless you use "shellandwait" which is infinately more complicated than regular old shell. 
Just wanted to put things in perspective for ya.

Your comments bring me no revelations.  But more languages support the Windows clipboard than you think.  It is hands-down the most most universally utilized method for sharing data between programs there is.  Any language that does not provide support for it is more than a little lacking.  Which ones are you talking about where this is an issue?

As for the "extra memory" usage, it was assumed that the LED-Wiz user would want to take advantage of the Keyboard LED emulation for use with MAME.  This requires a resident program anyway, so everything else that software does is a "freebie."  Things are done a certain way for a reason, Howard, and the fact that you aren't aware of them, doesn't detract from their validity.

You seem to think I'm trying to be negative or just get on your nerves, I'm not.  I like the product, it works well and it's cheap, but the software doesnt work well and you have a stance of defending the software rather than trying to implement some of the suggestions is hurting the accessability of the product and probably the sales of the product.

No, I don't think that. But I do think you have a tendancy to see things only from your own perspective, even when others point out where it is askew.  I'm glad you like the product and I hope you have fun with it.  It's still one of my favorite toys.  But the resident software does exactly what it was designed to do and it does it well (given that it is admittedly incomplete in its current state.)  You don't like it because it's not the development tool you want it to be.  That's fine, because it wasn't designed for that purpose.  That doesn't mean it doesn't work well, it just means you can't make french fries in your toaster and that doesn't mean your toaster isn't working well.   

You defend the clipboard method as being for non-programmers and I tend to agree when it comes to a user just wanting to change the color of their lights or load a animation and that's it by writing the command in a text file and copying it, but considering how much work has to be done to get the clipboard to work correctly compared to just having a dll, command line inteface/active x/ect that uses the exact same commands and looks exactly the same but "just works" it seems like non-programmers that are writing their first little app are still going to find it easier to use something easier than the clipboard. 

If they aren't trying to do complex animations, they won't have any of the issues you are talking about, and the extra steps will be unnecessary.  If they are writing a "first little app" they won't be trying to get 20ms animation frames.  Again, if you have a better way for 2 separate, and unbeknownst to one another, applications to communicate, please make suggestions and provide examples.  If you really want to help, start there .

The flaw really lies in the command structure if you ask me.  It takes two commands to light a light (or bank of lights ect) instead of one. One command to turn the light on and another to set the intensity, instead of having the device automatically turn the light off when you set the intensity to 0 and automatically turn it on when you set the intensity great than 0.  Being able to set the intensity before lighting a light is definately a good idea as an option, because I can see real uses for it, but not as a requirement. 

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.

These are just suggestions, if you don't want to use em fine, but when something doesn't work well for me and I (sorta) know what I'm doing then it stands to reason that others will have similar issues.

When it comes to the LED-Wiz, I'm afraid you don't (or didn't) really know what you are doing.  Others have had discussions with me and have asked questions rather than going through this awkward "tit-for-tat" we are experiencing in this thread.  The experience of those individuals was not the same as yours.

Of course, that I know of maybe only 4 people are writing stuff for the ledwiz, myself included.  It might be related. 

There are quite a few more than that   The LED-Wiz has found a home for control applications outside of BYOAC.  I've had people who are using it for industrial applications, with some oddball specialized language,  tell me they couldn't believe how simple it was for them to control the device (yes, via the clipboard)  Up and running in 10 minutes, they said.  But again, those people are not interested in high-speed animation, so they don't have issues. 

It's all about using the correct tool for the job and asking questions rather than making assumptions.

RandyT

[Timoe]

Bah. 

Thats just too much text for me with a too-high Gorgon to English ratio.

Just make it so my panel will light up in and OUT of MAME, guys.

[Howard_Casto]

Randy you response was the one I expected making excuses instead of fixing problems... I'll quit trying to help, good luck to you. 

[RandyT]

Randy you response was the one I expected making excuses instead of fixing problems...

And your response to my points and questions is apparently just a lack of response, as I expected.

Howard, just because you perceive something as a "problem", does not make it so.   And that's all I have to say about that.....

RandyT

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

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.

That goes both ways, Howard.

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. 

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.

I think I stated that it was a good option to do it seperately but you shouldn't require it.

And, as I stated, It is not required.

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. 

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.

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. 

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.

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. 

No, this has not been established. 

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. 

  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?

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. 

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.

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. 

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.

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.

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]

us, that dosent use VB would still been easier to use a a dll.

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]

us, that dosent use VB would still been easier to use a a dll.

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.

Thanks for your input on the OCX compatibility issue.  That's good info to know.

I would like test that things.. but i don't have ledwiz...    Randy did you read my mail?

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

[Howard_Casto]

Well let me go down the list of how you are simply ignoring hte problems yet again!


Well you CAN'T do on and off animations, you can do on and off gimmick tricks.  The same gimmick tricks, I might add that you can do with a pen I bought at goody's for 2 bucks that has an ultra bright led in them.  And again I am NOT talking about animation, I'm just talking about setting the color.  Can't make a button pink without adjusting the intensity now can you?  Also you have to remember that any (well coded) application has to assume that another application could have already gotten ahold of the device and monkeyed with the settings and therefore it's good coding practice and pretty much required that even if you aren't going to mess with the intensites you have to set everything back to 48.  So I repeat again you HAVE to send two commands when dealing with rgb leds.  And no the intensity doesn't default to 48, once one program sets it to another intensity it stays that way until a new intensity is set.  I know because I'm sitting here doing it right now. 



And yes, it is indeed required.... if I set the intensity of a light to 27 nothing happens until I first turn on the light state.  Now a person with sense would have put a command in the ocx, clilpboard commands, ect that allowed you to do both at the same time... you don't have to do anything to the hardware, just have the interface method know that when this new command is sent, to send both commands to the device.  Since only one command is transmitted over the clipboard, all of the timing issues are magically gone for novice users as now they can actually light some colored lights with only one command.  I'm literally gonna fly to your house and slap you silly you you can't see the logic in that.  I'm sorry I just had to spell it out so bluntly for ya.  You really need to start listening to what I say instead of what you think I say. 


No developers are certainly NOT made aware of these concerns.  You don't have ANY data posted on your site other than the commands you can send.  By your own admission on your own site this is considered a developers tool, I shouldn't have to email you back and forth until I get all the answers I need, they should be posted clearly on the site.  Don't agree?  Well I'll get to that in a minute.  I found a powrmame thread a while back in which poor old mike worked for hours trying to figure out why some of his users were having the exact same timing issue I've described.  He didn't get a single reply by you to that thread. 



Ok the "beta" animation editor that has been out for a year now and is the official software for the product.  By your own admission it's a commerical product right?  Ok so let me get this straight, you have released a product that doesn't have any software, doesn't have a reliable interface method other than copying and pasting from a text file and doesn't come with a dll for developers to interface with it?  I don't think I even have to say anymore on that one. 

And yes it does very much effect a stand alone app, because it stands to reason that many users are going to want to use the resident app for other things or for testing.  Once that intensity has been set to 0 by another app there is no way for them to get it back up, save deleting the cfg for ledwiz87.  I try to look at all possible problems myself, not just the ones I can write off as unlikely. 


How in the blue hell can you get an agenda out of what I am suggesting?  I have an ocx that works.  I also have mikes dll that I can get to work if I write a wrapper for it.  I'm talking about issues in your software and issues with the clipboard method.  If my "agenda" is to make your product operable out of the box so it'll sell better and thus be more widely accepted by the community and as a result be spported in more arcade realted applications then yes, I have that agenda.  Darn you caught me, what an evil person I am trying to help both you and the community as a whole.  I'll tell you what, I'll just stand against this cross with my hands out-stretched and you can go ahead and drive the nails in yourself. 

Yes, it's a commerical product... billed as a developers product.  Which means either you give them a professional way to inteface with it, or you write software that is NOT beta they can use to inteface with it.  I'm just using what you've told me here.  And actually the code commander guys have all the specs I would need to inteface with their product plainly posted on their website.  They seem to realize that when you sell an i/o kit you need to tell developers how to...well i/o with it. 

I apologize about the last one, you are right out of the developer's enviromnet it works fine.  Respectfully though the original ocx didn't do this.  I'm not sure what has changed but it really threw me for a loop. 

I feel bad yelling at you I really do, but it seems like you don't even start to consider our advice/complaints unless we all "gang up" on you like we did in this thread.  Remeber if you truely did make this device for this community then when somebody like me or sf or anyone willing to write free software for you which will help sell your product your response should never be "no" it should always be "let me see if I can do that".   I don't think I have made any insaine "demands"  here  I asked that you post more details about the ocx and clipboard method on your site.  I asked that you make the ocx visible and downloadable and accessable from your site.  And I suggested you make a new command-line inteface that uses your ocx (or direct communication method since you can do that too.) So that it would work better.  It'd take you all of 5 minutes to make one... there's nothing to it.  Since you dont seem to be willing to do those I just asked for the system device interface commands.  Since you product is obviously based on a generic HID chip kit and we are all buying the hardware, not the firmware and you don't have a non-beta, official application for end users to use, this seemed like a fairly reasonable request to me. Haven't you ever heard of "the customer is always right"?  

Btw, with respect, the appripriate response to SF is "I'll get right on that" not "I'll take that into consideration".  He's right, about the ocx's they are all but extinct.  And when a vb6 freak like me tells ya that, you know it's true.  I like em personally, but it would make a lot more sense to write  a dll and document that.  Even though dlls are more complicated to setup it's well documented in all languages on how to set them up.  Seems like a fair trade-off to me considering ocx's don't work too well in anything other than a vs6 language.  Also there is the annoyance of having to have a form in your app.  Not a bid deal, i'm just saying.  Broadcasting is also a very nice method... I don't prefer it though because it's a little "wonky" but it works well and it's fast.  I'm using it for an upcoming app that gets the romname from an open mame instance.  It's really fast and works really well.  Also it takes nearly no computer resources to poll a window caption (once you get the handle of course) as quickly as every 2ms because windows already has the window caption of every parent window stored for use in the taskbar and taskmanager and aparently regularly polls them itself. 


Now chill this time man, no point in us getting all angry again.  Just don't reply if you don't want to.  Go to your happy place.

[Space Fractal]

yep, dlls is maybe not the easiest to do in Visual Basic, but it darn simple to use them in other langauges! As Im know

I'm simply created a little wrapper for the bass, when I created AMB. Then all commands sent to the wrapper was pure basic commands, that was easy to use.

Yes ocx is mosly for MS language, like Visual Basic, but not all like that language. Some may prefer Blitz+(like me) or other very cheap language (like Pure Basic). Blitz+ is one of the language, that is so simply to use dll

[RandyT]

Howard, I'm not going to go back through all of what you wrote and point out where you see what you want to see, where you go on about interactions between people you just aren't privy to , how you compare apples to oranges, and the numerous places where you are just plain wrong.  But all of those things are indeed happening in your post, along with the usual sprinklings of insanity that seem to pervade all of what you do.

I'll leave this thread with the following so you can go back to doing whatever it is you do;

The current Multi-device ActiveX control is free, as was the one before it.  There is no extra charge or limitations placed on you or anyone else who wants to use it, provided they do something constructive for this community with it.  I just spent the last week working on it because one of my customers has been very patient and very nicely requested a way to let him programatically control more than one LED-Wiz.  This support was never promised, but I have delivered it and not made a single extra nickel in doing so.  I have also not even begun to break even on the work done on the LED-Wiz product as a whole.  They sell from time to time, but unlike the company who "has everything you could want as a developer on their site", we don't charge$20 for just a chip.  Everything comes at a price.  Take a close look at your LED-Wiz, Howard.  Each of those 29 components and 160+ solder connections were put in place and fully tested by a skilled human who actually gave a crap about your happiness when you opened the box and plugged it in for the first time.  If the market was larger, we could mass produce them and let our customers do our QC like some other vendors do, but it isn't and we don't.  And those things don't even begin to address the efforts made in the board design, firmware and software phases.  The next time you feel the need to "protect my customers" you be sure to remember these little tidbits of info, ok?

Have fun comparing yourself to Jesus, I'm off to that happy place you mentioned.

RandyT

[loadman]

I have also not even begun to break even on the work done on the LED-Wiz product as a whole.  They sell from time to time, but unlike the company who "has everything you could want as a developer on their site", we don't charge$20 for just a chip.  Everything comes at a price.  Take a close look at your LED-Wiz, Howard.  Each of those 29 components and 160+ solder connections were put in place and fully tested by a skilled human who actually gave a crap about your happiness when you opened the box and plugged it in for the first time.  If the market was larger, we could mass produce them and let our customers do our QC like some other vendors do, but it isn't and we don't.  And those things don't even begin to address the efforts made in the board design, firmware and software phases. 

Some feedback

I bought one of these and there is no question of the quality of the product.  It is very well constructed and nice layout. Good work

The price is very low for the Hardware you receive.

My view is I would have been prepared to pay a fair bit more if the software suited my gaming needs.

[Circo]

Agreed, I would pay more for working software.  That's nothing new, wonderful product, just wish it worked 

I wonder if Randy has left the thread?

With working software you would definately sell more so that's a positive.   

[RandyT]

Ok, I'm back from my happy place and read your post again.  I don't want anyone to think that my silence gives credence to the erroneous information you have purveyed, so I need to address that, at minimum.

And yes, it is indeed required.... if I set the intensity of a light to 27 nothing happens until I first turn on the light state.  Now a person with sense would have put a command in the ocx, clilpboard commands, ect that allowed you to do both at the same time... you don't have to do anything to the hardware, just have the interface method know that when this new command is sent, to send both commands to the device.  Since only one command is transmitted over the clipboard, all of the timing issues are magically gone for novice users as now they can actually light some colored lights with only one command.  I'm literally gonna fly to your house and slap you silly you you can't see the logic in that.  I'm sorry I just had to spell it out so bluntly for ya.  You really need to start listening to what I say instead of what you think I say. 

Maybe you should be using the RGB command that has been in the resident application nearly since the day it was released.  The syntax is:

LWZ-RGB:<starting output number>, <Red Value>, <Green Value>, <Blue Value>

One command, sets the color of an RGB LED and turns it on for you.

The equivalent for the new OCX is the same, sans the "LWZ-" part

I found a powrmame thread a while back in which poor old mike worked for hours trying to figure out why some of his users were having the exact same timing issue I've described.  He didn't get a single reply by you to that thread. 

MIke and I were furiously exchanging emails at that time.  Just because you aren't part of something doesn't mean it isn't happening.

How in the blue hell can you get an agenda out of what I am suggesting?

Your comments in this thread were made long before you even ran your hands across a unit, and to this day, you have not asked any intelligent questions about how best to interact with the device.  Based on outward appearances, you have problems with the clipboard method because  you wish to.

Since you product is obviously based on a generic HID chip kit and we are all buying the hardware, not the firmware and you don't have a non-beta, official application for end users to use, this seemed like a fairly reasonable request to me.

Howard, WTH are you talking about?  Not buying the firmware?  There is nothing "generic" about the functions provided by the LumAura™ engine firmware in the LED-Wiz, or the protocols and methods used to communicate with it.  48 levels of PWM on each of 32 individual outputs with built-in,  selectable,  host-independent pulse modes coded in pure assembly pushes the envelope of what is even possible in a low cost device.  And it took me weeks of mind-numbing work to make it possible.

You are "obviously" on crack if you think the LED-Wiz, or any of my products for that matter, are based on any "generic kit"

Broadcasting is also a very nice method... I don't prefer it though because it's a little "wonky" but it works well and it's fast.  I'm using it for an upcoming app that gets the romname from an open mame instance.  It's really fast and works really well.  Also it takes nearly no computer resources to poll a window caption (once you get the handle of course) as quickly as every 2ms because windows already has the window caption of every parent window stored for use in the taskbar and taskmanager and aparently regularly polls them itself. 

Ok, now please describe "wonky" and point me in a direction so I can look into it.  Better yet, it should be pretty simple for master programmer such as yourself to "knock out a wrapper for the new OCX" so's you can show me how it's done.  But I realize that such a thing is not your responsibility, so...links please.

RandyT

[buks]

I've been following this thread (and all the ledwiz threads) and just wanted to throw my 2pence in.

Yes the BETA software that comes with the ledwiz doesn't work 100% BUT you can create animations, you just cant edit them.

Yes PowerMAME is probably frozen at version 105 but the functionality of the attract modes, button lighting etc is pretty cool. In fact, its more that pretty cool. I totally understand MikeQ's reluctance to continue with the project and HowardC is right in saying that the way forward is to do all that stuff in an exteranl app.

Randy has made a superb product that really looks good. Call me sad (and I know some of you will) but I sometimes just load up mamewah and watch the animations and mame movies (running as a screensaver).

Mahuti has created a superb app to allow the powermame attract mode functionality to run in the frontend (mamewah in my case). It does has speed issues with my setup - maybe others don't.  And I dont think the speed issues are to do with clipboard stuff either - mahuti doesnt code in c so i suspect its down to his choice of language.

I really dont want to start an argument with Howard as reading his posts without stepping back for a moment can make you think hes just been arrogant when in fact he (mostly) is trying to help - but some people may think that from his comments in this post that the ledwiz doesnt work as expected (or isnt up to scratch). Maybe thats down to peoples perception and not what hes saying - I just wanted people to know that I've got stuff working as I want.

Having said that last bit - I'm very interested in what Howard is coding at the moment. I've downloaded it but it complains about a missing ocx - ledwiz.ocx. I presume I need to pm randy to get that ?

Anyway, I might have already posted this before but heres a very low quality vid of my ledwiz in action (in marble madness using powermame) - http://www.anti-particle.com/videos/buks_panel_vid.asf

Now everyone take a deep breath, and lets have a group hug

Buks

[Howard_Casto]

Randy the problem is you don't document any of this.  It's probably a honest mistake but you don't.

This rgb command you mentioned for example. 

I just looked at the included docs in the ledwiz.zip... doesn't mention the command. 

Looked in the ocx docs... it's in there but it doesn't mention any of this about it automatically turning on the lights, so I had to assume that it was just another way of setting the intensity. 

Also it says that the rgb command doesn't allow you to use custom pin order.  That's fine if you are using your leds, but many of the rgb leds out there have a strange pin order. 

The command to launch a LWA file isn't anywhere btw... I had to figure that one out by using mahuti's cool little app.

I'm sure that you were helping out mike, cause there's no way he could have gotten as far as he did without your help... not just because you are a nice guy that way and are smart enough to figure out the problem, but because your docs are kinda shabby.  But the fact of the matter is, if you don't respond publically then the conversation never happened as far as the rest of the world is concerned which is a very bad thing in this case.  If you guys would have posted your findings then everyone (myself included) would simply reference the thread whenever the issue arises again with something else.  It's just like the delay thing with the clipboard.. you were very quick to point out the cause, but it isn't mentioned in the docs anywhere or anywhere on your site... it needs to be. 

I'm guilty of not documenting stuff in my apps too, it happens.  Of course my stuff is free and isn't the dependant app for a commercial product. 


I should publically castrate you for the insult to my programming skills but I'm trying to be civil.  I don't write ocx's as nobody but me codes in vb, "real" programmers hate em (read anyone using a C based langauge, even visual c) and thus I'd be trading files with myself.    Broadcasting is real easy to do... you just read a window's caption.  To the end -user writing a program, all they have to do is change the caption of their app... no sweat it's usually something like "me.Caption=Hello World".  What you would have to do is have your resident app periodicially search window captions for commands by either enumerating all windows and using the "getwindowtext" api for each window handle, or by searching for a specific class name (that the user defines as a setting in the resident app) which would be much fater. 

The reason I say "wonky" is because of the whole enumerating windows thing.  When you know what you are looking for broadcasting is super fast because you can just check for "Window A" and only have to get one window handle. It's easy to get mame's broadcast, for example, because mame has a "mame" class name so you can just look for that one window and you don't have to know the caption.  When you aren't then you have to look everywhere.  Checking each caption takes no time, but getting the handles to each window running might.  There are ways around it.... you can only check the foreground window via "getforegroundwidnow" api or only check the active window but that might not be the best method for your purposes as applications trying to communicate might be hidden and thus they are never "active" and aren't even visible. 

Buks I agree with everything you said well almost everything.  My point kinda was that the ledwiz doesn't work 100%.  It isn't due to the hardware though, the hardware is great and works as it should.  But the software it comes with isn't there yet and the docs aren't full enough to do the things that don't work in the resident app manually, at least not to the average user.  But the software can be brought up to speed very quickly, just by fixing the bugs in the app regarding layout files and giving us an interface method in addition to the command-line app.  It's around 75% functional now if you aren't comfortable with manually typing commands and only use the official ledwiz software.  Powermame and mauhti's app have a pretty steep learning curve too as well as j5, so those are out.  Fix two or three things though and it's there, that's what I've been saying all along.  Remember buk, you even said yourself that you don't use the ledwiz app for much and are using stuff like powermame, mamewah, ect to actually set the lights/lwas.  That's how it should be, I'm just saying isn't exactly turn-key.

Btw... sorry about the ocx... I've upped a newer version of the app that includes the new ocx and liscense.  It does some other nifty test stuff so have fun. 

[buks]

Thanks Howard, I'll give it a go tonight.

Buks

[RandyT]

Randy the problem is you don't document any of this.  It's probably a honest mistake but you don't.

This rgb command you mentioned for example. 

I just looked at the included docs in the ledwiz.zip... doesn't mention the command. 

You are correct.  The docs for the resident software are lacking.  However, it was mentioned in the LED-Wiz thread on this board.  Specifically, in this post.

The RGB command was not implemented in the first OCX, therefore it was not included in the instructions.

Looked in the ocx docs... it's in there but it doesn't mention any of this about it automatically turning on the lights, so I had to assume that it was just another way of setting the intensity. 

Well, it says that the example command "Produces a “warm yellow” color on an RGB LED connected starting at output #4", which it can't do unless the output is on, but no, it does not specifically state that it turns on the output after setting the intensities. 

There is an error in another part of the documentation though, which I just found.  The control was still evolving when the documentation was written, so the RDC and RDI commands will not work as written.  They require an additional "Affect State" parameter.  If set to 0 it will not change the current states of the outputs.  If set to "1" it will activate (turn on) the output as part of the command.

Also it says that the rgb command doesn't allow you to use custom pin order.  That's fine if you are using your leds, but many of the rgb leds out there have a strange pin order. 

I can't believe you actually wrote this.

I'm sure that you were helping out mike, cause there's no way he could have gotten as far as he did without your help... not just because you are a nice guy that way and are smart enough to figure out the problem, but because your docs are kinda shabby.  But the fact of the matter is, if you don't respond publically then the conversation never happened as far as the rest of the world is concerned which is a very bad thing in this case.  If you guys would have posted your findings then everyone (myself included) would simply reference the thread whenever the issue arises again with something else.  It's just like the delay thing with the clipboard.. you were very quick to point out the cause, but it isn't mentioned in the docs anywhere or anywhere on your site... it needs to be. 

I'm guilty of not documenting stuff in my apps too, it happens.  Of course my stuff is free and isn't the dependant app for a commercial product. 

Howard, there are an awful lot of reasons why one doesn't publicly share everything that is discussed between developers / manufacturers / business partners.  I don't expect you to understand them, but I'm also not going educate you in business practices in a public forum.  But I will say that a big one is the avoidance of consumer confusion.  As buks alluded to, a casual (non-programming type) might look at a conversation like the one we are having now and think something is "terribly broken", when in fact most of the discussion is purely academic.  Buks' control panel footage and the quiet enjoyment of the product by the hundred+ or so other users prove this to be true.

I should publically castrate you for the insult to my programming skills but I'm trying to be civil.  I don't write ocx's as nobody but me codes in vb, "real" programmers hate em (read anyone using a C based langauge, even visual c) and thus I'd be trading files with myself.   

I don't think I insulted your programming skills.  Had I, the post would have read rather differently.  I merely prompted you to "put your money where your mouth is", something the overtly vocal are so very often loathe to do.  As for writing an OCX, I don't think I asked you to do that either.  A standard .DLL, suitable  for use by "real programmers" would also be 100% acceptable.  BTW, an awful lot of software used in this hobby is written in VB.  A quick load of an executable into a hex editor will show you that one if in doubt.

Broadcasting is real easy to do... you just read a window's caption.  To the end -user writing a program, all they have to do is change the caption of their app... no sweat it's usually something like "me.Caption=Hello World".  What you would have to do is have your resident app periodicially search window captions for commands by either enumerating all windows and using the "getwindowtext" api for each window handle, or by searching for a specific class name (that the user defines as a setting in the resident app) which would be much fater. 

The reason I say "wonky" is because of the whole enumerating windows thing.  When you know what you are looking for broadcasting is super fast because you can just check for "Window A" and only have to get one window handle. It's easy to get mame's broadcast, for example, because mame has a "mame" class name so you can just look for that one window and you don't have to know the caption.  When you aren't then you have to look everywhere.  Checking each caption takes no time, but getting the handles to each window running might.  There are ways around it.... you can only check the foreground window via "getforegroundwidnow" api or only check the active window but that might not be the best method for your purposes as applications trying to communicate might be hidden and thus they are never "active" and aren't even visible. 

Well, in the same two paragraphs you have pretty much suggested a method and then shot it down for all of the very good reasons why it cannot be used in place of the clipboard method.  Enumeration does take time, which would vary based on the number of windows one had open at the time.  The windows would constantly need to be enumerated, because if they weren't, how could the software know when a new program had been launched?  As you stated, checking the foreground window's caption would be next to useless, as almost any application written to be "universal" would need to be running in the background. Furthermore, how could the resident program respond to an application, to let it know it was ok to send the next command? 

Perhaps the most interesting fact about the clipboard method you hate so much, is that none of the above are issues with it.  From everything I have researched, it really is the only way two programs, which are totally "unaware" of each other, can communicate universally.  I have received a few suggestions, but so far, none have been viable.  One of the more interesting has been a TCP/IP server setup, which sounds really cool, but comes with it the onus on the developer to be able to produce client software in their language. 

Any other suggestions?

RandyT

[horseboy]

I wish I knew what you guys were saying.  It sounds like a fun conversation.

[Howard_Casto]

Randy I don't mean to insult you, but you don't know anything about running a business or if you do you are purposefully doing the opposite of what you are supposed to do, if you did you would never talk so poorly to people in a public forum and you would be more willing to help.  You don't have to "school" me in the inner workings of business, my degree is in business, which is exactly why I am so critical about your dealings, particularly with the persentation of your products and dealings with the public.  You go against what is proper p.r. and practice bad marketing by releasing a product before the software is ready.  This very conversation is proof of it.  I can talk to you however I want, because I am the customer.  You can't talk to me however you want, at least not in a public forum because you are representing a company and your attitudes and choice of language/tone can sway potential customers from purchasing your products.  Is that fair?  Of course it isn't.  You have to deal with it though if you wish to maintain a professional image.  You have a right as a vendor to ignore me but when you do respond you have to be extremely careful with what you say.  That my friend is your business lesson for the day.

And the whole reason I refuse (you heard me refuse) to write a dll/ocx/ect for you is because that is your responsibility and you haven't made the tools available for me to do so.  Why in the world would I make you a new interfeace for free so you can make more money?  I'm helpful but I'm not stupid.  I think the fact that people in this community, including myself are willing to make software that uses your poduct and release it for free is more than generous.  And you should really be more grateful to us as at this point you are literally dependant upon the kindness of strangers.

I am sure that a percentage of customers are more than willing to buy your product and have it do nothing but display blinky patterns.  I'm also pretty sure that most of them expect it to do more than that and be useful for something.  And I'm almost postive that none of them bought it thinking that it would be a practical and cost-effective way to control the keyboard leds in mame.


Well the clipboard thing was more about me a sf talking about bypassing buddamame and using external sources to control the ledwiz, not a replacment for your clipboard method.  But you asked about it so I answered.  I can probably think of a dozen methods that would work... writing text files, a com object ect....  The easiest is winsock(basically tcp/ip like you said)... pop in the object..... set the url to the local address (127.0.0.1) and you have instant, reliable two-way communication between two applications.  You keep seem to come back to communicating with the resident app though.  Why do you need to ever do that?  If you are writing a program then you can bypass the resident app and you should bypass the resident app.  All the lwa files are are a series of regular commands put in a text file, and since that is the only thing the resident app can do that direct communication via dll/ocx/ect can't the whole resident app thing can be ditched?   What I am saying is leave the frikkin clipboard method in there if you wish, just take the comand-line app and have it work without interfacing with the resident app.  Then the clipboard method is no longer holding back the command-line app and programmers can interact with the device with something as simple as a shell call and don't even have to deal with shell and wait. Of course a proper dll also needs to be written.

I'm not in doubt about people writing a lot of stuff in vb, I'm just in doubt about a lot of people writing complex stuff in vb.  I push the poor thing to it's limits.  Most people just write simple stuff with it though.   I think the only hi-profile thing written in vb in the emulation community is the daphne-loader and it's being replaced. 

The thing about the clipboard is... I don't hate it, I just know how it works intimately and because of that I can see how things can go wrong.  The thing that pops into my head immediately that is actually used often with mame cab software is the printscreen function.  It uses the clipboard and is a clipboard hog.  Also users do it a lot externally.  And whenever you grab the screen, the data mode of the clipboard is changed.  In some languages the datamode is automatically changed when you go to set text, in others it isn't.  On top of that I also know that the time it takes for the clipboard to be filled and emptied is quite variable.  So variable that it isn't possible to predict how long it'll take for "function a"  to complete on all systems.  Also it's very dependant upon the os.  I could see m$ reformatting the clipboard in vista or even removing it in lue of something else. 

[RandyT]

Randy I don't mean to insult you, but you don't know anything about running a business or if you do you are purposefully doing the opposite of what you are supposed to do, if you did you would never talk so poorly to people in a public forum and you would be more willing to help.  You don't have to "school" me in the inner workings of business, my degree is in business, which is exactly why I am so critical about your dealings, particularly with the persentation of your products and dealings with the public.  You go against what is proper p.r. and practice bad marketing by releasing a product before the software is ready.

I guess that's where the textbook and the real world part ways.  In Utopia, yes.  But on this planet, it just doesn't work that way.  Just ask anyone with a real job in that sector.  You offer specific functionality that you make clear at the time of purchase and continue to work to the end you desire, increasing the capabilities of the device along the way to the delight of your customers (who were never promised the new functionality they eventually receive.)  Why do you think there are always so many firmware and driver upgrades?  Why would one not wait until every last part was done and totally bug-free? You don't want to wait that long because your customers don't want you to and your competition won't let you.

This very conversation is proof of it.  I can talk to you however I want, because I am the customer. 
You can't talk to me however you want, at least not in a public forum because you are representing a company and your attitudes and choice of language/tone can sway potential customers from purchasing your products.  Is that fair?  Of course it isn't.  You have to deal with it though if you wish to maintain a professional image.  You have a right as a vendor to ignore me but when you do respond you have to be extremely careful with what you say.  That my friend is your business lesson for the day.

Howard, you and I have history that precedes GGG and I'll talk to you as though you are the person you are, regardless of the license you think you have with me because I am a developer.  I don't have to castrate myself to run a business, and if you ever manage to get one under your belt, remember this: Right is Right and when there is a goofball "customer" who is intent on dragging your name through the mud for no other reason than his perverse self-gratification, you shouldn't allow yourself to be castrated either.  If you do not have respect for yourself, you cannot have true respect for others.  There's your lesson for the day.

That being said, I'm RandyT (Randolph Turner, if you prefer).  I don't represent anyone but myself and I have been in the hobby for the last 25 years and here nearly as long as you.  And here I will remain, regardless of your many attempts to discredit and discourage the things I have done.  As a long-time member of this community, I provide guidance where I can and listen to what people ask for.  Sometimes I even deliver it, and at a price well below what others would have you pay.  Glad to make your acquaintance.  May I speak my mind now?

And the whole reason I refuse (you heard me refuse) to write a dll/ocx/ect for you is because that is your responsibility and you haven't made the tools available for me to do so.

I can't prove that you are unable to do what you expect from others, so I will indeed take your word that you can... but refuse to.

And you should really be more grateful to us as at this point you are literally dependant upon the kindness of strangers.

You like to use the word "us" a lot, Howard.  How many here stand behind what you say?  From what I can tell, it's just you and I banging heads here, just like we have so many times in the past.  Your constant use of  "we" and "us" make it sound as though you have a virtual army of followers.  Is this truly the case?

And, FWIW, I don't rely on the "kindness of strangers".  Mostly because the developer types who contact me are often very friendly and knowledgable people.  They tend to be intelligent and polite.  People I enjoy exchanging ideas with and who I don't consider strangers after the first or second contact.  At times, I also provide hardware, free of charge,  to those who have previously demonstrated their commitment to this community as a whole and who don't do what they do for thinly veiled self interest.  Yes, it makes things better for me to do these things.  It also makes things better for you and everyone involved in this hobby.  If I didn't believe strongly in what I do, and have the passion to take people head-on who would stand in my way, I would never have invested the thousands of hours, and many thousands of dollars of my own money,  to make the products I sell a reality.  By your definition, everyone here relies on the kindness of strangers, Howard.  Even you.

I am sure that a percentage of customers are more than willing to buy your product and have it do nothing but display blinky patterns.  I'm also pretty sure that most of them expect it to do more than that and be useful for something.  And I'm almost postive that none of them bought it thinking that it would be a practical and cost-effective way to control the keyboard leds in mame.

I guess I was wasting my time doing market research and listening to the scores of folks who said they would be more than happy to be able to just set the lights to any color they wanted, light up the lights the buttons on their panel used in a specific game, and do a little animation in-between.  I guess I should have just asked you what everyone wanted instead.  I didn't realize that you spoke for so many here.

Trite sarcasm aside, it's natural for one to continue to want more and better things once the initial needs have been met.  The hardware has a lot of possibilities that go beyond what was originally considered adequate (or possible.)  One of the things responsible for the higher bar is PowerMAME.  It showed what the hardware could do in very talented hands.  Unfortunately, anything you or I provide will pale in the light of that software, as neither you nor I are MAME developers, nor have the resources to maintain a custom build.  And that is what will ultimately be required to provide the functionality that many will now seek.  But things didn't start that way such a short time ago.

Well the clipboard thing was ... <snip>

Everything you stated was in response to my specific question about a replacement for the clipboard method which you say should not be used.  Either what you suggested works as a replacement or it does not.  I am fully aware of the myriad ways to communicate between hardware and software.  Your rambling ambiguities related to COM objects, client/server applications and so on, does nothing to address the question at hand.  A TCP/IP situation is only viable if the developer can write a TCP/IP client in his/her language of choice.  If everyone can do that (show of hands please?)  then I will knock out a server in no time flat.  However, if only 10 or 20% have this ability, I won't waste my time as it does not address the needs of the product in the same way that the clipboard method does.

I'm not in doubt about people writing a lot of stuff in vb, I'm just in doubt about a lot of people writing complex stuff in vb.  I push the poor thing to it's limits.

I'm sorry, Howard.  I just completely lost it on that one.  You push VB to it's limits?  Weren't the earlier versions of Word, Excel and Access written in VB?  Isn't that the reason why VBA is so tightly integrated with those apps?  I don't think the software you write is worthy of a comparison to programs like these or others that truly do push the limits of the language.  Sorry.

The thing about the clipboard is... I don't hate it, I just know how it works intimately and because of that I can see how things can go wrong. The thing that pops into my head immediately that is actually used often with mame cab software is the printscreen function.  It uses the clipboard and is a clipboard hog.  Also users do it a lot externally.  And whenever you grab the screen, the data mode of the clipboard is changed.  In some languages the datamode is automatically changed when you go to set text, in others it isn't.  On top of that I also know that the time it takes for the clipboard to be filled and emptied is quite variable.  So variable that it isn't possible to predict how long it'll take for "function a"  to complete on all systems.  Also it's very dependant upon the os.  I could see m$ reformatting the clipboard in vista or even removing it in lue of something else.

First off, if you are trying to use the clipboard to playback animations while MAME is running, you have bigger problems.  I will try one more time, Howard;  You don't use clipboard command to try to playback frames of animation.  It's not fast enough and it was not designed for the task.  That is why the resident program has playback commands built in so that a user need only to tell the resident software what file to play and how many times to play it.  From that moment on, the clipboard is no longer utilized.  If I intended for it to be any other way, I would not have taken the time to build animation playback routines, rather left those to the developers.  One more time, DO NOT USE THE CLIPBOARD TO PLAY BACK FRAMES OF ANIMATIONS.  IT WAS NOT DESIGNED FOR THAT TASK.

Oh, and Microsoft has done some silly things in the past, but trust me, the standard clipboard as used by every program in the last 10 years is not going away.  Backward compatibility will be there for quite some time to come.


RandyT

[Timoe]

What does FWIW mean?


If I dont electrocute myself trying to figure out how to wire up an led, or worse yet, poke out my EYE with a resistor, this LEDWiz thing looks to be pretty exciting.

[horseboy]

For what it's worth.

[Space Fractal]

As I can see, LED-Wiz support may been dropped in Johnny5?  I can see myself, it would been very great, if it only lighted up these buttons, that was actuelly used by the game (does PowerMame that?).

Im still doubt the clipfolder method is used (if my doublt, should not been used). My self I used a hidden window with a speciel title to broadcastling with a Autohotkey script and AMB applicatrion. This was due for the Joystick support, since Blitz+ only supported 16 buttons, but GpWiz49 have 25).

I would even have a interest to create a simple LedWiz support, directly in Arcade Music Box. As I can see now, this would need to send a command to the clipfolder)? A dll would by me easier, since blitz+ only use dll, and it even not support clipfolder (but can create a dll in Pure Basic for that, so no problem).

A Another request is (wich is nothing about the clipfolder):
Since I dosen

[RandyT]

I can see myself, it would been very great, if it only lighted up these buttons, that was actuelly used by the game (does PowerMame that?).

Yes.  If I'm not mistaken, it will also speak to you and tell you the function of each as it lights them.

I would even have a interest to create a simple LedWiz support, directly in Arcade Music Box. As I can see now, this would need to send a command to the clipfolder)? A dll would by me easier, since blitz+ only use dll, and it even not support clipfolder (but can create a dll in Pure Basic for that, so no problem).

Supposedly, this DLL will let you use the clipboard from Blitz, and includes an example.

A Another request is (wich is nothing about the clipfolder):
Since I dosen

[Space Fractal]

I have found some issues:

- When "LumAura Control" are open, the commands to clipfolder dosen

[loadman]

Has anyone used this OCX successfully using anything other than VB6? 

I can do it all in VB6  But....Not with Delphi ...yet?

It is probably just me.....  but I am get 'Access violation'errors galore!!

This is guts of the code:


unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  LEDWiz_Control_TLB, StdCtrls;

type
  TForm1 = class(TForm)
    Edit1: TEdit;
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
   Wiz: LED_Wiz;
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.FormCreate(Sender: TObject);
begin
   Wiz.Command := 'RGB:1,13,22,40';

end;

end.

[youki]

I would have create an instance of the OCX , using : CreateOLeObject function before accessing to method or property.

Here an example (in DELPHI , and the same in VB)  , not wiz the ledwiz OCX but i could help you.

How to use COM component/object in DELPHI?
1. COM Init
  Example:
    var ConvertCom: Variant;
    ConvertCom := CreateOleObject('czxls2htm.ConvertApplication');
2. COM Property
  Example:
    ConvertCom.Visible:=true;
3. COM Method
  Example:
    sResult:=ConvertCom.ConvertFolder('c:\*.xls','d:\',false,'');
4. Close COM
  Example:
    ConvertCom:=UnAssigned;


How to use COM component/object in VB?
1. COM Init
  Example:
  set ConvertCom=CreateObject("czxls2htm.ConvertApplication")
2. COM Property
  Example:
    ConvertCom.Visible=true
3. Com Method
  Example:
    result=ConvertCom.ConvertFolder("c:\*.xls","d:\",false,"")
4. Close COM
  Example:
    set ConvertCom=nothing

[loadman]

Thanks Youki,
I Think I did successfully Import the Active X controll in VB6 and in Delphi using the GUI's

I have no problem controlling the Wiz under VB6.

My problem is now how to issue it commands in Delphi Format/syntax as  obviously it differs from VB6 . The instructions from GGG it only has VB6 type command examples.

I emailed you the OCX and its pdf instructions etc. If you have time if you could show me how to issue commands using Delphi 7 and I will make a donation to the Atomic fund ~~ even though I use MaLa  :-)   

Is there a chance that this OCX does not work with Delphi 7?

Thanks in advance (if/when you have time)

[youki]

For All  willing control LED-Wiz from delphi with the OCX.  This is how to do :

Add in the uses clause : ComObj

Code: [Select]

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls,OleCtnrs,ComObj;

then in your code. (here an example, that init the Ocx , and just light on all leds :

Code: [Select]

procedure TForm1.Button1Click(Sender: TObject);
var
 LedwizObject: Variant;
 MyString : Variant;
begin
   LedwizObject := CreateOleObject('LEDWiz_Control.LED_Wiz');

   LedwizObject.DeviceNumber:=1;
   MyString := LedwizObject.Detected;
   LedwizObject.Command:='SBA:255,255,255,255,2';

end;
I just tested that with Delphi 7 , it works.    It will be the same method for all other language.
(Variant and CreateObject or a kind of)

The OCX , need to be previously  regiestered by the command : regsvr32 <path>\LEDWIZM.OCX

 

I will make a donation to the Atomic fund ~~ even though I use MaLa

I don't want a Donation from a Mala user , i don' t accept dirty money!!    (i'm joking)

But thank for the proposition, but you can use that money to have a drink offered by me!  

[loadman]

I don't want a Donation from a Mala user , i don' t accept dirty money!!    (i'm joking)

And they say you don't have a sense of Humor    

Thanks Again, !!!!  As they say in Australia, 'You are a good sport'

But I will Donate!   

[LATER] That indeed does work. I am already on my way building my first real Delpi Prog.

Note: I did not need to register the OCX using the method you described to get it to work.  It probably already was.

Thanks Again

[youki]

[LATER] That indeed does work. I am already on my way building my first real Delpi Prog.

Note: I did not need to register the OCX using the method you described to get it to work.  It probably already was.

Thanks Again

As you already used in VB6  or tried to import it in Delphi using the U.I  , it has already been registered.  But in general case, the OCX need to be registered in the registry to works.

Thanks for the donation,  It wasn't really necessary ,  but i 've really appreciated!.

[loadman]

Thanks again

Here is my crappy test code.

4 Buttons to change 4 RGB Leds. 3 are on Wiz one, 1 is on Wiz Two

unit LedWiz2;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs,ComObj, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    Button4: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
    procedure Button4Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);

  private
    { Private declarations }

  public
    { Public declarations }
    m_LedwizObject: Variant;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
 LedwizObject: Variant;
 MyString : Variant;
begin
    m_LedwizObject.DeviceNumber:=1;
   m_LedwizObject.Command:='RDC:1,1';
end;

procedure TForm1.Button2Click(Sender: TObject);
var
 LedwizObject: Variant;
 MyString : Variant;
begin
    m_LedwizObject.DeviceNumber:=1;
m_LedwizObject.Command:='RDC:4,1';
end;

procedure TForm1.Button3Click(Sender: TObject);
var
 LedwizObject: Variant;
 MyString : Variant;
begin
    m_LedwizObject.DeviceNumber:=1;
 m_LedwizObject.Command:='RDC:7,1';
end;

procedure TForm1.Button4Click(Sender: TObject);
var
 LedwizObject: Variant;
 MyString : Variant;
begin
           m_LedwizObject.DeviceNumber:=2;
   m_LedwizObject.Command:='RDC:1,1';
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
    m_LedwizObject := CreateOleObject('LEDWiz_Control.LED_Wiz');

end;

end.