internal VS external application

Forum for software developers to discuss BCI2000 software development
Locked
tiziano
Posts: 18
Joined: 19 Oct 2008, 10:22

internal VS external application

Post by tiziano » 22 Nov 2008, 05:25

I'm going to implement a BCI Speller based on Motor Imagery with some predictive features.
I'm in doubt about whether to implement the module inside the BCI2000 framework or to build an external application using the AppConnector interface.
I've read what is written here http://www.bci2000.org/wiki/index.php/T ... _Connector but some points are not very clear for me:

First:
In contrast, control of an external device using the External Application Interface implies that the configuration of the external device has to be done outside of BCI2000, that this corresponding configuration is not stored along with the data file, and that the internal state of the output device is not saved together with the brain signals
I understand the problem of the configuration but why state signals can't be recordered together with brain signals? Isn't it possible to write state values to the UDP socket?

Second:
Such a case might be the control of external applications that practically do not allow full incorporation into the BCI2000 framework (such as the Dasher system for efficient low-bandwidth spelling).
Why was it better to implement Dasher as an external application? What do you mean for "efficient low-bandwidth spelling"? In my application there will be some some computational demanding tasks in order to perform letter and word prediction. Would this impact on my choice?

Third:

I'm not really sure about the GUI framework used in BCI2000. Is VCL used also to draw the CursorTask graphics? How OpenGL is used in BCI2000?
My plans were to use wxWidgets in order to get a platform-independent GUI. What do you think about that?

Thank you very much for your help!

Tiziano

mellinger
Posts: 1210
Joined: 12 Feb 2003, 11:06

Post by mellinger » 22 Nov 2008, 06:54

Tiziano,

thanks for your well-informed questions.

ad 1)
As you say, it is possible to write state information from an external application into BCI2000. To be able to encode all relevant aspects of your application's state into BCI2000 state variables, you will need to introduce your own state variables, which is possible through the operator module's INSERT STATE scripting command.

The remark on the AppConnector page was making a general point about preservation of information, thus not being perfectly precise. I added a note there to avoid misunderstandings.

ad 2)
The Dasher program existed as an external application. Its source code would have needed adaptation to compile under the Borland compiler. Thus, it was far more practical to add a few lines to Dasher in order to implement the AppConnector protocol on its side, than it would have been to incorporate it into a BCI2000 application module.

Quoting from the Dasher web site (http://www.inference.phy.cam.ac.uk/dash ... mmary.html):
"Dasher is an information-efficient text-entry interface". Making efficient use of the information provided on the input side, Dasher can be connected to low-bandwidth input methods such as gestures, eye trackers, or BCIs, and still achieve spelling at a reasonable speed.

Regarding your application, it is difficult to imagine that letter and word prediction would be computationally demanding on today's machines in a way that would influence your choice whether to implement it inside or outside BCI2000. In case computational demands would actually violate the realtime constraint that applies to BCI2000 components (i.e. all computations must be finished within the physical duration of a data block), you could still run your application's more demanding routines asynchronously inside a separate thread.

Rather than by computational demands, your choice would be determined by factors such as re-use of existing code and compatibility of development environments used.

ad 3)
The GUI framework in BCI2000 is an abstraction layer that currently uses the Borland VCL but is designed to simplify transition to platform independence in future versions of BCI2000.

We actually intend to replace the Borland VCL with wxWidgets in future versions of BCI2000. In case the existing GUI framework provides the kind of objects you need, it might well be that replacing VCL with wxWidgets calls there would be more efficient than writing your own class hierarchy from scratch.

OpenGL is used to draw 3D scenes in the CursorTask application. A 3D scene is just another GUI object that exists inside a sub-rectangle of an output window. The scene itself is populated with 3D objects that are independent of BCI2000 GUI objects (see http://www.bci2000.org/wiki/index.php/P ... nce:3D_API for an overview).
In the CursorTask application, the user can switch between a display mode that uses the 3D API to display graphical objects, and one that uses GUI framework objects for this purpose.

Regards,
Juergen

Locked

Who is online

Users browsing this forum: No registered users and 26 guests