This could be significant to LEDWiz/PM:

[Silver]

Aarons planning something:

"Tomorrow I

[Silver]

Abstracted the notion of outputs. A new module, output.c, now controls
all outputs. Each output is tagged with a name; some standardization
eventually needs to happen on these names, but at the moment it's
fully open. The OSD layer can register with output.c to be notified
when outputs change. From there, it is free to do what it wants. LEDs
have now been converted to outputs with the name "led0", "led1", etc.
[Aaron Giles]

Added support for notifying external clients of changes in output
states in the Windows OSD system. See windows/output.h for a list of
messages that external clients can register to receive. Removed the
built-in hacky LED support in the Windows OSD layer. Created a sample
application ledutil.exe which subscribes to the external events and
routes the "led0", "led1", and "led2" outputs to the keyboard LEDs
just like before. If you want to continue to have LED support, simply
copy ledutil.exe into your startup folder and let it run in the
background. [Aaron Giles]

Modified the Q*Bert driver to signal a "knocker0" output when the
knocker is triggered. [Aaron Giles]

[GlennEdwards]

Just read Aarons "update part 2" http://aarongiles.com/?p=181#more-181

This is great news!! I'm sure someone could write an LEDWiz "listener" app, that could drive the LEDwiz. Unfortuntely it still wouldn't provide the functionality that PowerMAME does i.e. attract modes, light up game controls, speech etc

I'm going to send an email to Aaron, asking if he can enhance his new output signalling system to also send out windows messages containing the name of a rom when a rom is executed, and a windows message when the rom is exited, and also a pause/unpause message. That way an LEDWiz listener app could pick up those windows messages, and from the rom name, process the appropriate lighting sequences, and also perform the speech function when pause is pressed etc..

Glenn