HyperSpin Event Dispatch System (EDS)

[Antos]

HyperSpin Event Dispatch System (EDS)

View File

---

To give Hyperspinners more flexibility, here is Event Dispatcher System (EDS) that allows HS to launch as many external applications on HS events that you like. This should be beneficial for the community where basically, this is a tool to extend Hyperspin possibilities and let users manage multiple applications on HS events.

 

EDS NEWS UPDATE - 2016/12/30 - EDS (Beta Release version 0.8.1) is now ready for download. ** Need advanced testers / testing **

********************************

DOWNLOAD: https://1drv.ms/f/s!Agk4mB5EbfOGhnPPoot0ymchQwqG

********************************

Bug reported by Scoodidabop for system & rom parameters  when it have embedded space(s). EDS was not working properly in this situation within 0.8.0 . Problem now fixed.  

Setup:

1. Please do a backup of your previous EDS files.
2. Provide edit rights to your new EDS folder.
3. Rename "EDS_LaunchModule (Rename me!).exe" to "LedBlinky.exe"
4.  Configuration Process:- Pipe does not launch [application].exe anymore, only CLI and Pipe (CLI) mode does. To continue using pipes within Hyper Marquee (recommended option) simply check "Launch Application on Front-End start" checkbox within EDS GUI configuration module, put '1' in the Open filter and '2' in the Close filter

EDS NEWS UPDATE - 2016/12/26 - EDS (Beta Release version 0.8.0) is now ready for download. ** Need advanced testers / testing **

What's New; (a short video for 'dummies' should come soon!!)

• EDS has change his business logic (major change approach). EDS is now persistently open (look in tray) during your gaming Front End session. This will prevent EDS to open and close (load/save & reload itself) at each HyperSpin/EDS event. It should also prevent EDS settings file to get corrupted sometimes. It should be faster to respond, but taking a little more memory and CPU during gaming (less than 1% more).  
• Add Key Commander embedded application to launch & close applications on dedicated key stroke. Useful to custom/ad-hoc speech, High Score and control panel display!
• Add a check box to decide if the mouse pointer will be sent to screen Top Left corner at EDS start up or not.

---------------------------------------------------------------------------
Installation & Instructions (quick one from Sevenseal)
---------------------------------------------------------------------------

NB: key requirement; install .Net framework 4.5.1 or higher

1. Make sure that system users have read, write & execute access of the EDS folder and the content (Windows setup 10 behavior). (right click on folder go to properties/security)

1.1.: Within your EDS folder, rename "EDS_LaunchModule (Remane me!).exe" application to "Ledblinky.exe" (mostly for HS users)
1.2.: Configure and enable EDS within your favorite Front End. Within HyperHQ.exe goto the "Tools" tabs, set the path for EventDispatchSystem root folder and enable LEDBlinky checkbox.

2.: Run "HyperSpinEventIntegrator.exe" (EDS GUI) to configure your external apps that you would like to use. (see posted video at thread #308 for more instructions)

2.1: Application (first table column): Specifying application .exe directory location

2.1.1: Example path for Application
- LEDBlinky - C:\Hyperspin\LEDBlinky\LEDBlinky.exe (reference to the real ledblinky if you have the hardware)
- HyperMarquee - C:\Hyperspin\HyperMarquee\Hyper Marquee.ex
- HS FileWatcher - C:\Hyperspin\EDS\HSfileWatcher\HSFileWatcher.exe (not needed in HS 1.4 or higher)

2.2: IPC Methods (3) - CLI, Pipe & Pipe (CLI) - See application guide for more explanations.
2.3: CBR: Close Before Rerun, avoid using with IPC Methods: Pipe or Pipe (cli). But it must be checked for CLI applications.(Excepted for Leblinky.exe)
2.4: Parameters: Inputs are place in this order [event], "[system]", "[game]" or [ledblinky] or blank for no parameters used.

2.4.1: Event ID (Ledblinky compatible)

• Front-End Start (1)
• Front-End Stop (2)
• Game Launch (3)
• Game Stop (4)
• Screensaver Start (5)
• Screensaver Stop (6)
• System Select (7)
• List Change (8)
• Game Select (9)
• Animation Stop (11)
• Load MAME Controller File (12)
• Reset Ultrastik 360 (13)

2.5: Pipe ID : For HyperMarquee, this is the name title of the named Pipe to send the message between EDS and the remote application (HyperMarquee).
2.6: Event Filter : The specified events list accepted parameters to launch the application. input table refer to 2.4.1
2.7: Close Filter : This feature allows closing the application using its Process ID (PID) for application that does not manage closing by themselves. input table refer to 2.4.1
2.8: System Filter : This feature allows restricting the remote application from being launched by all System (emulator) but the defined ones.
the remaining setting are self-explain

3.: Configure and enable EDS within your favorite Front End. Within HyperHQ goto the "Tools" tabs, set the path for EventDispatchSystem root folder and enable LEDBlinky.

~Settings: HyperMarquee in conjonction with EDS can be launched different ways according to what you are trying to achieve. As you know, there are 3 IPC methods - CLI, Pipe and Pipe (CLI) - that you can used. Out of those 3, 2 are workings without issues, but could present some minor limitations depending on what you are trying to do. For myself, I am always using 'Pipe' for HyperMarquee and not using CLI or Pipe (CLI) methods. I strongly recommend using 'Pipe' when calling HyperMaquee as your first pick, than CLI. Finally Pipe (CLI) may offer more flexibility with certain risks/complexity. For 'Pipe' option, make sure to check the check box called 'Launch Application on F.E start'. This checkbox will launch applications on F.E. start that has event 1 set in the Event Filter column. The 'Pipe' advantages; The fastest to launch, fastest inter-communication, and best interactivity. For all other applications that are not compatible with pipe IPC, use CLI and make sure to check the checkbox 'CBR'.

~(this is a beta evaluation version for testers only)
Please send me your comments and first impressions. (it is recommended to read the user guide first - then try, ask & comment)
Debugging and support: Thanks for your comments and involvement to make this application bug free and stable. The final release V.1.0 is coming soon, getting there. As soon as the application is fully stable (close but not 100% there yet). !!!!! If you report bugs or problems, (sometimes due to miss understand on IPC methods), please make sure that you help sevenseal and I to understand by providing very explicit information. That will save you time and save us even more time. Explicit information are; your settings file, the EDS error log file, what you are trying to achieve, and if you can (ideally), a simple video.

Special thanks to:
- Sevenseal, Brolly, Gooch, djvj for advises, support and graciously volunteer for beta testing.
- Bad Boy Billy for great inspiration and Hyperspin Frontend.
- Users! (To report bugs or improvement ideas)
- My Girlfriend France, who always supports me

 

VIDEO
-----------------------

Useful video from mamefan

 

Quick EDS video (very technical): Ok, producing videos is not my cup of tea, but I feel this short video might be useful to understand EDS core functionalities and general approach.
This is a humble video providing the basic concept of the HyperSpin Event Dispatch System (EDS). The frame rate is low and may not give you the real response time difference between CLI and NamedPipe. Volume is also a little low, my apologies.

 

Also, please see post #188 from Event Dispatch System threads for a quick step by step trouble shooting.
http://www.hyperspin-fe.com/forum/showthread.php?32782-HyperSpin-Event-Dispatch-System-(EDS)/page19

 

DONATION
-----------------------
This is free and it will always be. To encourage development, you can send a donation of your choice. You can proceed with Paypal to;

- Antos (conception and development - Status: Active member)
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=E7R4KGFDJ3PAU&lc=CA¤cy_code=CAD&bn=PP-DonationsBF%3abtn_donate_LG.gif%3aNonHosted.

- Sevenseal (newly added member - user support, documentation, testing, research - Status: Active Member)
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=M2ZA3T2ZZMFSE

-----------------------
SCREENSHOT
-----------------------
EDS GUI Front-End screenshot

---

• Submitter
  Antos
• Submitted
  05/08/2015
• Category
  Add-Ons
• Credits
  Antos, Sevenseal, Brolly, Gooch, djvj and all testers.

 

[albert]

wonderful if you can make that gives support to two or more monitors inside the marquee and HyperSpin menu showing data from each system.

[Antos]

Some useful documentation on ledblinky from Pietie

http://www.ledblinky.net/Install.htm#StandAloneMode

Recorded the actual commands HyperSpin sends and found the following:

On Window Focus

LEDBlinky.exe 4

I think the main reason for this one is if you exit a game and return to HS. But tabbing out and back will also cause it to run this STOP command.

System select

LEDBlinky.exe 7 "Steam"

Game launch

LEDBlinky.exe 3 "10-Yard Fight (USA, Europe)" "Nintendo Entertainment System"

Note the order is [rom name] [system name]

I'm not sure what the '3' is for but HS sent it with.

Game select

LEDBlinky.exe 9 "Beamrider (USA)"

So this is called every time the select item on the wheel changes. Again, I'm not sure what the 9 is for.

Going back to main wheel

LEDBlinky.exe 8

And then of course it also sends the FRONTEND START/STOP commands. Hope this helps!

[Antos]

Got it & did it!!!

I have a proof of concept of a Hyperspin Events Dispatch System (EDS).

Using Pipes.

How it works,

1. HyperSpin calls the EDS (left form with the grid) - need to rename EDS by LEDBlinky

2. EDS send messages (asynchronously) to all systems. Systems that you have earlier specified, in order to send hyperspin events to them (need to add a listener to your app - sample code will be provided)

3. EDS is closing after sending messages (ie Hyperspin event)

4. Your application can use what as been asynchronously received.

[brolly]

Looks good, I can see this being very useful.

I think that if instead of passing the messages through you add some mapping configuration where you allow the user to map each of the LedWiz messages to different message formats this could be used with basically any application.

Why do you need to use named pipes for this? Using pipes for IPC might not be that simple depending on the language the applications are coded in. For me the easier way would be to simply invoke the applications with the specified CLI arguments, but of course running applications would need to support receiving CLI arguments while running.

Also using pipes will only allow you to communicate with already running applications, what if the application isn't supposed to be running and needs to be launched instead? You should consider adding support for this too.

[pietie]

Why do you need to use named pipes for this? Using pipes for IPC might not be that simple depending on the language the applications are coded in. For me the easier way would be to simply invoke the applications with the specified CLI arguments, but of course running applications would need to support receiving CLI arguments while running.

Also using pipes will only allow you to communicate with already running applications, what if the application isn't supposed to be running and needs to be launched instead? You should consider adding support for this too.

I agree that you need to support launching new processes. But in my case HyperSearch should already be running so some sort of IPC works better for me. I also only allow one instance of my app so if its just CLI I would need to handle that myself.

[Antos]

Your comments are very appreciated. They are directly contributing to make this application possible.

Based on your comments, the good news is that I can certainly include more than one calling method to support third party applications nature or suitable behavior. I guess only a few methods will be enough. (2 that I can think of)

There are two major drivers in order to make this application a reality. (As of now, I do not see any technical barriers)

Drivers ;

1. Dealing with the HyperSpin given environment. (a contraint in this particular case)

2. Understand third party application needs and expected behavior. (they are starting to flow in)

1. HyperSpin given environment;

After some quick testing on HS LEDBlinking calls, this is what found;

- HS is calling & opening 1 application at the time and always the same LEDBlinky.exe (we all know that)

- HS do not create an handle with the application and will not close it.

- If the application doesn't close by itself, Windows will quickly run out of resources by creating too many instances.

2. Thirds application behavior use case;

2.1 - Some applications need to stay open and need to prevent HS to open a new one each time HS makes an new call. (Actual solution pipes).

- Need communication between .exes. Ways to support this, that I am aware of; (pipes (socket), TCPIP, WCF, config file)

- Advantages: Better memory management, lighter on memory, spooling and CPU.

- Advantages: Excellent for apps that displays graphics to leverage on transition effects and animation.

- Disadvantages: More complex to implement, IPC might be a challenge depending on the language the application is developed in (Brolly is right). (I can create a dll to avoid this being language dependent.)

2.2 - Some applications are light and close by themselves after each HS call once their stuff is done. Like LEDBlinky. (easy case)

- CLI call with arguments will do the job perfectly.

- Advantages: Easy to implement, no external management is required. (other than Close option)

- Disadvantages: Will launch multiple instances if not managed, apps needs to shut down before each calls. Could be heavier on spooling if the app is not lightweight.

Outstanding questions;

"what if the application isn't supposed to be running and needs to be launched instead? You should consider adding support for this too. ". Yes absolutely, there two easy ways to handle this that I can think of;

Answer;

from scenario 2.1;

1. Launch the application if the IPC calls failed (socket pipe, supported by All POSIX systems, Windows) after a few milliseconds.

2. use MUTEX. Launch the application if the mutex check (GUID). (if yes, use it, otherwise launch)

from scenario 2.2.

1. Auto close previous after doing their things (like LEDBlinky) - application owner management required.

2. Launch the application if the IPC calls failed using mutex by checking if the GUID exists. (if yes, close it, then launch new)

Let me know.

PS: English is not my first language.. Hoping that my text is readable

[brolly]

I think the best way is to make the application launching mode configurable. Speed is of essence here so wasting cycles trying to make an IPC call is no good, also this way it will have the advantage that later down the road if you want you can easily add different methods like using WCF or something else.

So for each application just add a new setting for this, if nothing is set default to pipes for instance.

Regarding auto closing this is also something that should be dependent on the application. Some applications might auto close themselves others might want to remain open and will capture the newly sent CLI arguments while others will remain open forever and those you should probably close them on your end before launching them again to avoid ending up with a bunch of instances running. So again imo you should make this configurable to the user so you can support all scenarios, a setting such as Auto-Close=true/false should be enough.

And your English is more than fine.

[Antos]

I think the best way is to make the application launching mode configurable. Speed is of essence here so wasting cycles trying to make an IPC call is no good, also this way it will have the advantage that later down the road if you want you can easily add different methods like using WCF or something else.

So for each application just add a new setting for this, if nothing is set default to pipes for instance.

Regarding auto closing this is also something that should be dependent on the application. Some applications might auto close themselves others might want to remain open and will capture the newly sent CLI arguments while others will remain open forever and those you should probably close them on your end before launching them again to avoid ending up with a bunch of instances running. So again imo you should make this configurable to the user so you can support all scenarios, a setting such as Auto-Close=true/false should be enough.

And your English is more than fine.

Good points, thanks.

I will develop an evolutionary prototype for us to comments and adjust as we go.

There will be two modules;

- Hyperspin Events Dispatch System - Configuration module (visual API - not launched during gaming)

- Hyperspin Events Dispatch System - Launch module (very light weight, invisible to users - no GUI , functional API only)

[brolly]

Sounds good, I'll be happy to help testing it when you have something ready.

[gooch]

Please don't tell me this thread has gone dead. This is very needed with HyperSpin front-end development dead.

[Antos]

Hi Gooch,

I have good news, I have put many planning & coding hours on this last few months and I am happy to mention that it works fine as a pre-release version.

I am doing some alpha testing on it right now, and so far, I am very happy with the results.

I am hoping to release a first beta version for testers sometimes in July... ...2014 This will coinside with HyperMarquee new release.

[gooch]

Fantastic!

[Antos]

See first post of this thread for some updates.

Cheers!

[gooch]

Is there any consideration going into HyperSpeech integration? It also is an LEDBlinky redirect (like I assume EDS will be). I *think* boogieman opened up HyperSpeech code to the community, so we've got that working for us.

[Antos]

I must confess that I haven't seen what boogieman has done, I am assuming it is based on ahk scripting, isn't the case? (I will definitely have a look at it)

Yes, EDS is also a LedBlinky redirect and a multiple dispatch system. EDS is not based on AHK, it's a GUI and a custom dispatch engine using two InterProcess Communication (IPC) options for now, i.e CLI and WCF Named Pipe (have a look at the user guide for details and advantages). The EDS engine and GUI use a different approach, i.e it doesn't require any coding knowledge or scripting knowledge.

Since this initiative is completely free, the main objective is to give more than one choice to the community with more alternatives and options. Don't take me wrong, ahk is very good.

EDS code will be an open source solution for the developer community. So contributors are welcome to participate.

Is there any consideration going into HyperSpeech integration? Right of the bat, this is two very different technologies, but if there is a justification/reason on why this should be integrated, then sure why not. Hoping that you will like EDS and it will suits your needs and expectations. I will do a video too, just before release.

Thanks a lot for your input!

[Antos]

Here is the reason why I have chosen WCF Named Pipe to develop EDS. After the pain of developing it, it brings the best performance by far compared to any other options that I know of. Having to reload an application each time that you are changing your artwork using CLI and ahk, it is not even close to match the performance of WCF Named Pipe. EDS in conjunction with HyperMarquee will NOT have to reload each time your artworks and text get updated. Letting Hyperspin do is job with minimal resources demand and sharing.

See here some performance specs provided by Microsoft. CLI is not in the graph, since this solution is not an option when it comes to those technologies.

Although, EDS will still permit the use of CLI with good support options et flexibility.

Performance;

Request/Reply Named Pipe Application

The cross-process named pipe is used as the transport protocol along with request/reply as the message exchange protocol. As seen in Figure 12, WCF outperforms .NET Remoting by 29% and 30% for message payloads of 128 bytes and 4k bytes, respectively. As the payload grows in size, the performance of the technologies converge so that for the 256k byte array the performance is nearly identical.

This Figure, the corresponding data for quad processors is shown. The throughput of WCF is better by 38%, 18% and 28% for message payloads of 128 bytes, 4k bytes and 256k bytes, respectively.

[Fettsvett201]

Any chance of CPWiard Integration? Would love to be able to see a control panel layout for the game on my stretch monitor.

Thanks

[gooch]

Any chance of CPWiard Integration? Would love to be able to see a control panel layout for the game on my stretch monitor.

Thanks

There's CPWizard integration with HyperLaunch, or does it not do something you need it to?

[Antos]

Any chance of CPWiard Integration? Would love to be able to see a control panel layout for the game on my stretch monitor.

Thanks

I just did a quick visit to CPWizard web site and based on the app usage I saw (CPWizard.exe -emu mame -game 1942 ), EDS should launch this fine using CLI. This still needs to be tested, but I can't see why it wouldn't work.

Within the parameter column, using EDS fields, like this; -emu "[system]" -game "[game]"

Would you like to test this after release?

Thanks.

[gooch]

I must confess that I haven't seen what boogieman has done, I am assuming it is based on ahk scripting, isn't the case? (I will definitely have a look at it)

Yes, EDS is also a LedBlinky redirect and a multiple dispatch system. EDS is not based on AHK, it's a GUI and a custom dispatch engine using two InterProcess Communication (IPC) options for now, i.e CLI and WCF Named Pipe (have a look at the user guide for details and advantages). The EDS engine and GUI use a different approach, i.e it doesn't require any coding knowledge or scripting knowledge.

Since this initiative is completely free, the main objective is to give more than one choice to the community with more alternatives and options. Don't take me wrong, ahk is very good.

EDS code will be an open source solution for the developer community. So contributors are welcome to participate.

Is there any consideration going into HyperSpeech integration? Right of the bat, this is two very different technologies, but if there is a justification/reason on why this should be integrated, then sure why not. Hoping that you will like EDS and it will suits your needs and expectations. I will do a video too, just before release.

Thanks a lot for your input!

I guess 'integration' is a poor choice of term. I guess I'm just trying to see that if a redirect is used, a double redirect would work. Ie - HyperSpin > EDS > HyperSpeech > LEDBlinky, or HyperSpin > HyperSpeech > EDS > LEDBlinky.

The reason I bring this up is that there was another redirect I tried to chain like this once before and it didn't work.

[Antos]

I guess 'integration' is a poor choice of term. I guess I'm just trying to see that if a redirect is used, a double redirect would work. Ie - HyperSpin > EDS > HyperSpeech > LEDBlinky, or HyperSpin > HyperSpeech > EDS > LEDBlinky.

The reason I bring this up is that there was another redirect I tried to chain like this once before and it didn't work.

Is there a way to change the name of the thread? The right name should be Event Dispatch System (EDS)

So the redirect chain of this system is: HyperSpin -> EDS -> any remote applications(LedBlinky, HyperMarquee, HyperSpeech etc...)

EDS can launch 1 to many remote applications asynchronously. So EDs have only one main mandate, manage* one to many apps on HS events. *Manage= Launch, send messages & close apps.

[Antos]

After a lot of work, more than expected as usual, this project (EDS - initial Beta Release Version) is now available for download. This is an evaluation version for beta testers only.

Please send me your comments and first impressions. See first post of this thread for download.

A video shall come soon. (although, English is not my mother tongue, volunteers are welcome to produce a short video as a user guide ).

Thanks,

[brolly]

Nice work man looking forward to check it out, I'll give it a try asap and let you know how it goes.

[Antos]

Nice work man looking forward to check it out, I'll give it a try asap and let you know how it goes.

Sounds good, Thanks!