| Main > Software Forum |
| If you would like to build multi LED-Wiz support into your software... |
| << < (5/9) > >> |
| 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. --- Quote from: Howard_Casto on July 29, 2006, 05:04:41 pm ---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. ;) --- End quote --- 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 --- Quote --- 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. --- End quote --- 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. --- Quote ---How in the blue hell can you get an agenda out of what I am suggesting? --- End quote --- 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. --- Quote ---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. --- End quote --- 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" --- Quote ---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. --- End quote --- 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:
--- Quote from: Howard_Casto on August 04, 2006, 01:23:19 am ---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. --- End quote --- 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. --- Quote ---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. --- End quote --- 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. --- Quote ---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. --- End quote --- I can't believe you actually wrote this.:) --- Quote ---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. ;) --- End quote --- 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. --- Quote ---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. :) --- End quote --- 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. --- Quote ---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. --- End quote --- 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 |
| Navigation |
| Message Index |
| Next page |
| Previous page |