Difference between revisions of "Contributions:BCPy2000"

From BCI2000 Wiki
Jump to: navigation, search
(Source Code Revisions)
(Version History)
Line 16: Line 16:
===Version History===
===Version History===
BCPy2000 1.0 will be uploaded on 30.09.2008
30.09.2008 BCPy2000 1.0
===Source Code Revisions===
===Source Code Revisions===

Revision as of 18:48, 30 September 2008


BCPy2000 takes the C++ out of BCI2000 programming. It is aimed at developers of new applications and new signal processing methods, providing a platform for rapid, flexible development of experimental Brain-Computer Interface systems in Python. It takes advantage of various high-level Python packages: VisionEgg[1] for stimulus presentation, NumPy[2] and SciPy[3] for signal processing and classification, and IPython[4] for interactive debugging.

You can program a python-based application module, signal processing module, or even a signal source module for generating custom test signals and playing back data files. Each module can open an IPython shell in which you can inspect and interact with every aspect of the running system. If you're using a BCPy2000-implemented source module, you can slow the system right down or even step through packet-by-packet, which can help you while you're interactively debugging your python code in one of your other modules with pdb.

BCPy2000 implements a lot of infrastructure that allows you to get an application module running quickly. It also contains a set of optional tools, which are still a work in progress, but which are rapidly turning into a kind of "standard library" of Pythonic signal-processing algorithms and stimulus widgets.

The source code is available under the terms of the GNU General Public License v3.





Thomas Schreiner, Jeremy Hill, Christian Puzicha, Jason Farquhar

Version History

30.09.2008 BCPy2000 1.0

Source Code Revisions

  • Initial development: XXXX
  • Tested under: YYYY
  • Known to compile under: ZZZZ
  • Broken since: ----


BCPy2000 have whatever parameters you want to define in your own python module implementations. There are a few that it implements in the framework already, however:


This boolean, defined by the application framework, determines whether a signal-packet clock should be shown in the bottom right corner of the screen.


Your experiment need not be trial-based, but there's a flexible and automatic way of keeping track of trials within blocks, and blocks within runs, if you choose to design it that way. The self.design() application API method helps you set this up, and this parameter, defined by the application module, specifies the number of trials in a block.


This defaults to 1, so we usually consider a "block" to be the same thing as a "run". However, we once designed an experiment where multiple blocks of trials where recorded continuously in one file, along with the inter-block rest periods. So that had multiple BlocksPerRun. The self.design() application API method allows you to configure this.


The default speed at which the Python source module sends its artificial signals through the system. The default value of this parameter, 1.0, means real time.


An arbitrary string describing your Python application module's behaviour, filled in by the self.Description() hook in your BciApplication class implementation.


An arbitrary string describing your Python signal-processing module's behaviour, filled in by the self.Description() hook in your BciSignalProcessing class implementation.


An arbitrary string describing your Python source module's behaviour, filled in by the self.Description() hook in your BciSource class implementation.


BCPy2000 modules have whatever states you want to define for them in your Python implementation. However, the application module framework defines one or two already:


This is used as a poor substitute for stimulus timing information when a physical synchronization signal is not available. It is set automatically whenever a phase transition occurs, and its value lets you localize that event in the data stream with reasonable precision. Type self.doc('Timing') at one of the BCPy2000 modules' shell prompts for more info.


If you have chosen to implement a trial-based experimental design, this state variable keeps track of the trial number.


If you have chosen to implement multiple blocks per run in your experimetnal design (see the parameter BlocksPerRun) then this keeps track of the block number.


A clock stamp that tells you when phase transitions occur (probably superceded by the simpler-to-use EventOffset mechanism, but let's see).