Simon includes a context layer that allows you to let Simon automatically adjust its configuration depending on its context.
For example, you could set up Simon to only allow commands like "New tab" if Mozilla Firefox is running and the currently active window.
There are three major areas that contextual information can influence:
Scenarios can specify to only be active during certain contextual situations. If these situations are not met, Simon will temporarily deactivate the affected scenario.
The local context conditions of this scenario are shown in the list of Activation Requirements and can be added, edited and deleted through the respective buttons.
The context conditions respect a possible hierarchy of scenarios: The activation requirements of all direct or indirect parent scenarios also apply to the child scenario(s). This condition "inheritance" is shown on the right side.
The Simon main window also shows a list of currently used scenarios. Scenarios that are deactivated because of their activation requirements (context conditions) are listed in light gray and italic. The screenshot below, for example, shows a temporarily deactivated Amarok scenario.
The same visual hints (gray, italic font for unmet activation criteria) also apply to the individual context conditions in the context menu.
Every sample recorded with Simon is assigned a sample group. Sample groups can be configured to only be used for the building of the acoustic models if certain contextual conditions are met. If this is not the case, all samples tagged with the deactivated sample group will be temporarily removed from the training corpus.
For more information, an example use-case and instructions on how to work with sample groups, please refer to the section on sample groups.
In Simon, context is monitored through a set of context condition plugins.
In general, context conditions are combined through an "and" association. For example, if the activation of resource is bound by two conditions A and B, it will only be activated if both A and B see their conditions met. To instead model alternatives ("A or B or both"), use an Or Condition Association.
All conditions can optionally be inverted. Inverting a condition means that it will evaluate to true if it would otherwise evaluate to false and vice versa.
True, if the title of the currently active foreground window matches the provided window title.
The D-Bus condition plugin allows to monitor 3rd party applications that export state information on D-Bus.
The monitored application needs to provide two methods: One signal to notify of changes and another method that returns the current state.
The screenshot above, for example, configures a D-Bus condition that will evaluate to true while the music player "Tomahawk" is playing and to false otherwise.
The face detection condition will evaluate to true, if Simon's vision layer has identified a person sitting in front of the configured webcam.
This condition plugin will return true, if the given file contains the provided content.
The file will be monitored for changes.
The lip detection condition will evaluate to true, if Simon's vision layer has identified a person sitting in front of the configured webcam and is speaking something (lip movements).
The lip detection training will try to determine the optimal value of sensitivity of the detection by monitoring your lip movements. For better accuracy of lip detection condition, stop training when the sensitivity value on the slider during training becomes almost constant.
The or condition association allows you to configure a meta-condition that reports to be satisfied as soon as one or more of its child conditions evaluates to true.
Or condition associations can have an arbitrary number of child conditions that may even also be or condition associations.