#3 Implement Active Sensing from GUI to engine

[Nick Copeland]

There have been numerous problems reported on the Help forum with console debugging output. Evident from most of these is that the engine was still running from a previous invocation, something that happens if the GUI exits ungracefully - if there is memory corruption, which has been seen, then it is not always possible to request the engine exit too.

If active sensing was implemented the engine could detect GUI failure and exit if not seen. The code need to have sensing from the GUI to each emulation, not to the engine host code and could be implemented with SYSTEM code 124 which is still unused so can be inserted non-intrusively. The transmitter may need to send multiple active sensing updates if it is managing multiple emulations (for example dual manual synths or multiple windows). The receiver should only monitor active sensing once it has been received, that will allow for startup sequencing. When sensing fails the emulation should exit, and if no further emulations are active then the engine can exit pending the daemon flag.

To make this worthwhile it will have to be a default option that can be disabled on request so need to put in some very clear debugging when it fails. The reason it needs to be the default operation is that otherwise it will not be selected and loses all its benefits. The timers should be very loose since the goal is to have the engine exit when the GUI fails, not to time out when the system is busy.

Target it for 0.20.7.

[Nick Copeland]

Logged In: YES
user_id=1426398
Originator: YES

The active sensing is going to be one way, engine to GUI. The engine will know about GUI failure from the active sensing and the GUI will know about the engine failure since the TCP socket will fail on write() if the engine has exit. This is intentional however it may make sense to have it be possible to have this be bidirectional with status updates from the engine too, for other purposes.

[Nick Copeland]

Logged In: YES
user_id=1426398
Originator: YES

Implemented a one way sensing mechanism using two timers. One is the 'ms' rate of the sensing from the GUI to the engine (-activesense|-as) and the other is a value sent by the GUI to the engine in the active sense which is a millisecond validity/timeout of the message again in ms (-ast). If it expires then the engine will conclude the UI has exit. The code may be extended at a later date but it works now for an initial implementation.

Default timers are 1000ms for the message and 3000ms for the expiration. Code can be disabled with '-activesense 0'. All the timers are 'roughly correct' which means I don't uses systems timers, primarily period counts.

First release will now be 0.20.6.

[SourceForge Robot]

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).