Application Components

Written by Dominic Clifton

This is a short guide to my ideas about how to implement new drivers and software for the Ergodex DX1 and any other similar devices.

28/06/2009 - It's a little out of date now, but most of it is still correct.

There are three major components required for operation and configuration of one or more pads.

These are as follows:

• Pad Driver

Each pad requires a driver, the driver should be a driver that is common to all DX1 pads. A Pad driver needs to be made for each supported device. (Initially Erogdex's DX1, later maybe CH-Product's Multifunction Panel, Belkin Nostromo N52s, Frogpads, Saitek Eclipse I + Command Pad, Cherry Master-Xpress keyboards, Logitech G-15's, etc)

• Pad Monitor

The pad monitor handles usage of the pads.

• Pad Configuration Editor

The pad configuration editor will be the main user interface from which users will manage pad configurations and record and edit macros.

TODO

Primary goals

• Allow applications to directly send and receive data to a pad via pipes
• Allow applications to send keymaps to the device which are then processed by the driver which configured the device appropriately
• Work with more than one pad of the same type.
• Pass events to registered applications with as little latency as possible.

The pad monitor is the main part of the software that actually makes the device work. All the code for processing device requests and responses is handled by the pad monitor.

The pad monitor is to be written in C++ for maximum portability to Mac OS X and Linux.

Primary goals

• Run all the time a user is logged in
• Low memory footprint
• Be Fast (execution, start-up, reprogramming pads, etc.)
• Detect pad insertion/removal
• Uniquely identify pads
• Program pads with default configurations
• Handle execution of macros
• Detect application changes and reconfigure pads as appropriate
• Load pad configurations
  • When pad inserted/detected
  • When a notification is received from another application
  • When the configuration files are changed on the file system
• Handle starting of a separate macro recording application
  • needs to pass on which pad recording was started from
  • needs to pass on active application information (task name, exe's full path, parameters)
  • needs to pass on which pad configuration is active for the pad that recording was started from
  • needs to pass on when recording is stopped
  • needs to pass on which pad button to record the macro to
• Support a plugin interface for handling key event actions
  • events are (key or button pressed/released)
  • event actions could be: macro playback, midi command, launch app, switch app, etc
• Handle requests to change the status indicators from other apps
  • For example the macro recording app will want to make the red led flash
• Show the status of known and connected pads
  • e.g. one system tray icon or one per pad
  • change or animate the system tray icons according to pad status
  • show a status dialog when double clicked, status dialog should have a list of connected pads that can also be enabled/disabled from the UI.
• Store all application data in user profile, in XML.

Secondary goals

• not to interfere with the NVidia SLI enabling/disabling process. (The official Ergodex DX1 software *does* interfere and has to be closed and restarted before users can enable/disable SLI)
• detect fast user switching user changes (and reprogram the pad accordingly)
• Allow multiple users per Windows Login (the software will also support multiple logins - configurations to be stored user's profile)
  • Add a “Switch User” to the Status UI.

The pad monitor should be split into several key areas in order for porting to other operating systems to be viable. These are as follows:

• Pad Monitor core
• Request and Response processing
• Configuration file handling (loading and processing of XML files)
• Status UI
• Active application detection
• Plugins for handling events
  • Macro playback

The Pad Configuration Editor is to be written in C# to allow for rapid application development over portability. The fact that we require a rich UI that fits in with the host operating system's UI means that if the UI was to be cross-platform it would not be as rich as we want it to be. Also, some areas of the application are vastly different between operating systems (e.g. macro recording). The areas that are the same between different platforms should be written in separate class libraries that can be used on all platforms - e.g. loading, saving and parsing of internal data into XML, etc.

Primary goals

• Run on demand, not all the time, to avoid high memory footprint!
• Create, Modify and Delete pad configurations
• Show a multicolumn tree-view of pad configurations on the left
  • Tree nodes: all configurations, configurations by pad, configurations by applications
  • Columns: configuration name, pad usage (pad1, pad2), application name, layout name
• Create backups of pad configurations when record button is used (in case you screw up the recording!)
• Allow recording of macros without focussing (or even showing) the pad configuration editor
• Re-sizable window
• Define physical keyboard layouts
  • Allow user to and reposition the keys on the pad to match the layout of the keys on their device.
  • Assign keyboard layouts to pads
  • Assign background image to layout, show background image in UI.
• Define named key groups
• Define key actions
  • Single Key Action (e.g. Key 1 behaves the same as 'w')
  • Modifier Key(s) Action (e.g. Key 2 can be shift AND control)
  • Momentary Press Action (e.g. Key 4 can enable 'Key group 1' when held)
  • Cycle Action (e.g. Key 5 can enable 'Key Group 2' → 'Key Group 3' → 'Key Group …' → 'Key Group 1' each time it's pressed and released.
  • Use available plugins to perform additional actions
    • Macros (e.g. Key 3 can simulate pressing Alt+F, then 'x')
    • Launch and/or switch to App
• Key Actions should be able to have events (e.g. 'Key 6' could cycle between key groups and also use an event plugin. The plugin, for example, might update a status indicator either on a device or in the host os).
• Automatically save changes
• Communicate with the Pad Monitor when changes have been made.

Secondary goals

• Allow multiple users per Windows Login (the software will already support multiple users with different configurations as datafiles are to be stored in the user's profile)
  • Change the tree-view root node to “Users” or add a “Switch User” to the UI somewhere. I personally prefer a something in the tree-view so that you can see all the configurations that can be made active for the current Windows login as it aids copying/pasting between them over a “Switch User” control.
• Import pad configurations from the original Ergodex supplied software.
• Allow exporting of keyboard layout templates to vector file formats, so it can be loaded in Photoshop, etc.

It should be noted that because we eventually want cross-platform drivers that operating system specific information should be noted as such in any data files that are created so it can be handled appropriately by both the pad monitor and by the configuration editor.

I initially thought about being able to share pad configurations with users of other operating systems, but when it comes down to it the amount of work involved makes it un-worthwhile, especially when considering all the differences between the keyboards, joysticks and mice of the different OS's. At a basic level it'd be nice for application developers to include a single Ergodex configuration with their cross-platform software but it's doubtful they'd all be the same anyway, so initially don't expect a Quake 4 profile created on the Windows version of the software to load and work on Linux or Mac OSX and vice-versa.