Latest version 

Java-based Exploratory Data Analysis for EEG

User notes

 

Welcome

Getting started

For users

For developers

Introduction

This application can be used for performing a range of operations on EEG data files, up to and including visualization and scoring operations.

From the point of view of science, this program is notable for its flexibility regarding new analysis techniques. It makes heavy use of scripts and plugins, so that novel approaches to EEG analysis are as easy as possible to implement.

From the operational point of view, the program is notable for being largely driven from the command line, rather than a GUI. This style of operation pays dividends during the development and testing of methods, and during analysis of large numbers of datasets. In both situations, a GUI just gets in the way.

The following sections describe the principles underlying this application. They may make more sense if you first look at the later section Command line examples.

Design of Jeda

To top The task of converting a raw time-series recording into a more manageable set of scores seems straightforward, however there are innumerable opportunities both for innovation and for blunders. New ideas for analysis include: while the routine (but still error-prone) operations include

The design of Jeda tries to make everything possible within the generous limits of the chosen program framework, and to provide many simple and explicit (but non-binding) methods for performing routine operations. And to do all this within the reassuring environment of a strongly-typed object-oriented programming language.

The design of Jeda consists of a pipeline with six stages:

  1. Reading the raw data
  2. Time-series operations
  3. Epoch definition
  4. Epoch extraction and binning
  5. Transformations and scoring
  6. Display and export

This sequential design can deal with a lot of routine and non-routine requirements. However it does not provide for comparisons of individuals with groups, nor of groups with groups. This would be a major elaboration, and is not being considered at present.

CLI vs GUI

To top Jeda has a Command Line Interface (CLI) but no Graphical User Interface (GUI) — other than a simple demonstration program. The reasons are:
  1. pragmatic — development is easier without a GUI
  2. pragmatic — it is more sensible to refine core functionality before designing a GUI
  3. operational — batch processing is so easily accomplished with a CLI combined with a shell script
  4. operational — easy to report and reproduce an analysis, if it only involves CLI commands and scripts

Having said that, there are GUI components providing visualization options. So Jeda does provide a GUI experience where it matters. In the future a GUI will be layered on the existing code to help:

CLI Help options

To top Details of the command line options follow, divided according to the six phases of the overall process. But we first mention several general options:
-h This causes the program to print an outline of the program's command line options, and then to exit.
-eg This causes the program to print several examples of command lines, and then to exit.
-v This causes the program to print copious information reflecting its internal operation. Repetitions are cumulative (up to six, as in '-vvvvvv'), and produce additional diagnostics.
-q This causes the program to be 'quieter' in its output. By default the program shows only errors and warnings, but these can be suppressed by '-q' or '-qq'.
-props This is mainly of interest to programmers: it prints all the key=value 'system properties' that are intrinsic to this JVM instance, or that result from command line '-D' options.
-scripts This is mainly of interest to programmers: it prints the names of all the scripts under ./scripts/ChannelClasses/ and ./scripts/EpochClasses/ (or whatever directories are specified in the properties file). It also does a trial compilation of each.
-scriptsX This is like -scripts, but additionally shows detailed diagnostics whenever any compilation problems are encountered.
-mem This causes a window to be shown, containing a scrolling record of memory usage. It resembles Windows Task Manager.

Stage 1: Reading data files

To top The different representations of time-series (and, more challengingly, events) need to be transformed into a generic form, so that later processing stages can be independent of acquisition details. This is the main purpose of Stage 1 operations.

Currently the application can read the following formats:

There is also the possibility of concisely specifying a group of files to process, via a database query. This feature greatly aids in batch processing, especially when results are also output to the database.

-fn filename Name of input recording file, which may include directories but not wildcards. (Under Windows the ‘/’ directory separator goes the wrong way.)
-fq SQL_WHERE_clause If there is a database ('coreDB', say) relating file paths with other subject data, and if it has the schema specifically required by Jeda, then options like -fq "coreDB? paradigm='oddb' and age>25" can be used to process many files sequentially.
-fqq SQL_WHERE_clause This performs the same database query as the option -fq. However, instead of then processing all the chosen files, this version simply lists the file paths, after which the program exits.
-ff [ EEG | EDF | NS5 etc] Optional, since this is usually guessable from filename
-fileOverview Dump a one-page summary of the input time series data

Stage 2: Time-series operations

To top Time-series operations include re-referencing, filtering, DC removal, EOG artifact correction, extraction and elimination of specific channels.

It could also include operations that change the character of time-series (e.g. transforming ECG into heart rate), or operations that generate additional time-series (e.g decomposing EDA into separate SCL and SCR time-series).

Jeda handles this through customizable Java classes, which encapsulate all the required operations. The source code for these classes is compiled at runtime, yet is fully integrated with the rest of the program. This means that the Java classes can access handy utility routines from the main program, and be rather compact as a result.

-scriptChannel [dir/]filename Name of script file describing channel manipulations (e.g filtering or re-referencing). The path can be absolute or employ certain wildcards (i.e. it can begin with a slash, dot or tilde); otherwise it is taken to be relative to an implied directory specified by the property scripts.channelClasses=scripts/channelClasses. The default for this option is standard/Standard, which may be further abbreviates to Standard: either form refers to scripts/channelClasses/standard/Standard.java. Do not include the extension .java. The command line option -scripts may be used to list available scripts.

Interestingly, it is possible for the Java code to generate data de novo. Such 'mock' data is very useful for testing the subsequent stages of analysis. In this case it is unnecessary to specify the -fn option.

Also, it is possible to specify a series of scripts, to be run sequentially, e.g. 

    -scriptChannel mock_ec/DualAlpha:standard/HRpt
to generate artificial EEG and ECG data, and then to append a channel containing heart rate, derived from the ECG. [The usual caveats apply regarding file separaters ('/' and '\') and path separators (':' and ';') under Linux and Windows.]

Below is a list of available code for performing time-series operations. 

        scripts/channelClasses/
        |-- standard
        |   |-- AvRef.java
        |   |-- CzRef.java
        |   |-- ExtraEog.java
        |   |-- Grat.java
        |   |-- GratPreclean.java
        |   |-- HRpt.java
        |   |-- HRwqrs.java
        |   |-- Minimal.java
        |   `-- Standard.java
        |-- mock_ah
        |   |-- Modulated.java
        |   `-- Simple.java
        |-- mock_ec
        |   |-- DualAlpha.java
        |   |-- Grat.java
        |   |-- ModelEeg.java
        |   |-- Sine.java
        |   `-- White.java
        |-- mock_eyet
        |   `-- Simple.java
        |-- mock_faces
        |   `-- Simple.java
        |-- mock_gng
        |   `-- Simple.java
        |-- mock_let
        |   `-- Simple.java
        |-- mock_maze
        |   `-- Simple.java
        |-- mock_oddb
        |   `-- Simple.java
        |-- mock_ppi
        |   `-- Simple.java
        `-- mock_wm
            `-- Simple.java

The files specified by -scriptChannel are compiled at runtime, so can be regarded by users as scripts.

Stage 3: Epoch definition

To top The first stage coerced event information into time-stamped strings, however it is another job to turn these low-level events into labels having a semantic significance. Only when this is done can specific subsets of epochs be extracted with any degree of convenience.

For example, a stimulus event may be a 500 Hz tone, but from the experimental perspective this one physical event may need to be assigned different labels according to its immediately preceding stimulus, or whether there was a subsequent button response.

Realistically, these contingencies can't be anticipated by this program, so must be handled with code provided by the user, which computes the mapping from physical events labels to semantic events labels. As with Stage 2 operations, Java code is used, which is compiled at runtime.

This results in considerable flexibility regarding events. Indeed generating new events is a possibility. For example, new events might be created by examining the time series, and marking the onset of an hypoxic event, SCR, K-complex, peak of respiratory cycle, etc. All these operations may be encapsulated in a script.

The Java code specified by the -scriptEpoch option typically returns a table containing a number of rows (timestamps) and columns (event attributes). Another table is automatically generated that contains a number of rows (one per channel) and columns (channel attributes like name, position, transducer, etc). These two tables are copied to SQL tables, and selections can then be made using standard SQL SELECT statements. The resulting subset of events and subset of channels are then combined (an OUTER JOIN, in the language of SQL), giving a table with a number of rows (one per single trial waveform) and columns (comprising all event and channel attributes). This 'attribute table' is a general repository for all salient information associated with each single-trial waveform. In particular it is used in the next analysis stage to bin the single trials. (The options -labelXXX augment the attribute table by adding extra columns.)

Both the processed time series and the table of attributes are cached on the server. Thus an analysis can be repeated, or different binning tried, with little cost in time.

Command line options:

-paradigm subdirectory Subdirectory of whatever is indicated by the property scripts.epochClasses (whose value is typically scripts/epochClasses or scripts\\epochClasses). The default for this option is ec, while alternatives are oddb, ah, maze etc.
-scriptEpoch filename Name of script file enumerating potential epochs and their attributes (e.g stimulus, stimulus sub-types, reaction time, noise measures). The path can be absolute or employ wildcards (i.e. it can begin with a slash, dot or tilde) — in which case the -paradigm argument is ignored. Or else it is taken to be relative to an implied directory: the implied directory is formed by concatenating whatever is indicated by the property scripts.epochClasses, with the explicit or default value associated with -paradigm. The default for this option is Standard. Do not include the extension .java. The command line option -scripts may be used to list available scripts.
-eventSelection SQL_clause Event selection, e.g. "stim = 'Bg' and RT < 0.5" Note that the enclosing double quotes are essential, that enclosed strings like 'Bg' require single quotes, and that case is significant only for such strings. Def: select all available events
-chanSelection SQL_clause Channel selection, e.g. "mode = 'EEG' or site = 'SCL'" Another example is "Site like '_z'", which shows SQL pattern matching in action. Note that the enclosing double quotes are essential in order that the command line is properly parsed. Also SQL requires that enclosed strings like 'EEG' use single quotes, and regards case as significant only for such strings. Def: select all available channels
-labelString key=value one or more key=value pairs, where the value is a string§
-labelInteger value one or more key=value pairs, where the value is an integer§
-labelFloat value one or more key=value pairs, where the value is a float§
-labelDouble value one or more key=value pairs, where the value is a double§
-labelDate value one or more key=value pairs, where the value is an SQL-style date§
-labelTime value one or more key=value pairs, where the value is an SQL-style time§
-labelTimestamp value one or more key=value pairs, where the value is an SQL-style timestamp§
-previewSeries enable plotting of raw time-series
-reviewSeries enable plotting of preprocessed time-series

§ The same key=value pairs are assigned to each and every epoch. Such values are of no value in distinguishing epochs, so can't be used by this program. So what is their purpose? This feature allows additional information about the subject to be incorporated into the output, and this information will certainly be useful in later phases of analysis when combining results from many people. Ideally these later phases should not have to merge Jeda's data with data from other sources; ideally all relevant information should be encapsulated in Jeda's output, and these -labelXxxx commands are designed to do this.

See under scripts/epochClasses for examples of scripts that may be specified by -scriptEpoch: 

        scripts/epochClasses/
        |-- ah
        |   `-- Standard.java
        |-- ec
        |   |-- OneLong.java
        |   `-- Standard.java
        |-- eyet
        |   `-- Standard.java
        |-- faces
        |   `-- Standard.java
        |-- gng
        |   `-- Standard.java
        |-- let
        |   `-- Standard.java
        |-- maze
        |   `-- Standard.java
        |-- oddb
        |   |-- Standard.java
        |   `-- Synamps.java
        |-- ppi
        |   `-- Standard.java
        `-- wm
            `-- Standard.java

The file specified by -scriptEpoch is compiled at runtime, so can be regarded by users as a script.

Stage 4: Epoch extraction and binning

To top Attributes are crucial to advanced subsetting of epochs and to more experimental science goals. Examples of interesting subsetting that can be carried out are:
-transform [null|power|phase|sq] Optionally transform the epochs, and do so prior to binning. The default is null which implies time-series output.
-binV category Category used to distinguish the rows in multiple plots: category is any of the column titles in the attribute table
-binH category Category used to distinguish the columns in multiple plots: category is any of the column titles in the attribute table
-binZ category Category used to distinguish offsets within relevant plot styles: category is any of the column titles in the attribute table
-dumpRaw Dumps an ASCII representation of the raw data to the console
-dumpUnbinned Dumps an ASCII represention of all single trials to the console
-dumpBinned Dumps an ASCII representation of all binned averages to the console

If none of "-binV", "-binH", and "-binZ" are specified, then this stage outputs all selected single trials to subsequent processing stages.

If one or more of "-binV", "-binH", and "-binZ" are specified, then this stage outputs a 1- 2- or 3-way binning of the single-trials. This has the form of a data object comprising either a 'frame' of waveforms, a 1-D array of such frames, or a 2-D grid of such frames.

Very commonly 'Site' will be used as a discriminant, so that Fz, Cz, Pz etc are separately averaged. `Stim' is another common discriminant (and would, for example, result in separate 'Bg' and 'Tg' averages); however there is really no limit to what may be chosen. (The meaning of all this will be clearer after looking at the section Command line examples.)

Stage 5: Transformations and scoring

To top Some traditional scoring options have already been implemented, albeit simplistically. There should eventually be plug-ins for measuring coherence, gamma activity, regional phase synchrony, ICA decompositions, etc. Model fitting has already been implemented via a Java-C interface to the program eegfit.

In all cases the command line comprises what is essentially a function call, with (a) the name of the plug-in, (b) a list of argument=value pairs, and (c) a specification of which rows/columns should be sent to this plug-in.

-score ScoreOption(arg=val,...)[rows][cols] Carries out the specified transformation or scoring operation

There can be zero, one or more scoring options specified, and they are executed in sequence. The section Scoring epoched data explains more.

Run Jeda with the -h option, to see what transformation/scoring options have been implemented: "java -cp build frontendClasses.CLI -h"

Stage 6: Display and export

To top Some basic display and export options have already been implemented. There will eventually be plug-ins for dynamic spectra, topographic maps, plots emphasizing laterality, etc.
-display DisplayOption(arg=val,...)[rows][cols] Carries out the specified display operation
-output DisplayOption(arg=val,...)[rows][cols] Carries out the specified export operation

As with scoring, there can be zero, one or more display/export options specified, and they are executed in sequence. See the section Displaying epoched data.

Run Jeda with the -h option, to see what display/export options have been implemented.

Viewing continuous time-series

To top This style of visualization is available via the -previewSeries and -reviewSeries command line options. It enables the interactive display of continuous time-series.

Graphic of continuous time series

Note that the window contains an upper and lower panel: that lower shows the full duration of the available data, and is mainly used as a navigation shortcut.

Mouse actions are dependent on which part of the upper or lower panel the mouse pointer is located in. The area "North" refers to the band across the top, where event codes can be shown; "Center" refers to the plot area; "South" refers to the band across the bottom where the times are shown; "East" is where the channel information is shown; "West" is where the channel labels are shown. The effect of mouse clicks also depends on which button is pressed. The mouse wheel can be used to scroll vertically (where appropriate), but there are no double-click or click-and-drag operations defined, and Shift, Ctrl and Alt are ignored.

Mouse clicks are used to pop-up addition windows, to position cursors, and to highlight particular channels:

Area Left Middle Right
North Event display Event filter
Center Cursor 1 Help Cursor 2
South
East Select channel Waveform attributes
West Other wave info

The (proposed) Event Display window will enable events to be seen in tabular form, and the (proposed) Event Filter will help in showing only the relevant events. The two cursors can simultaneously defined, and a particular channel can be highlighted. Also the content of the left- and right-hand sides can be changed via right-clicks.

Keyboard actions control layout, and pop-up additional windows:

Key   Shift- Ctrl-
← → Scroll one page Change horizontal scale Step one event
↑ ↓ Highlight channel Change vertical scale Channel separation
Home Go to start of waveform
End Go to end of waveform
Space Scroll small step to right
BackSp Scroll small step to left
Key  
A About Jeda: HTML documentation
C Display common attributes
D Drill-down to single trials
E Toggle display of SEM
H Display a Help window
P Print window
Q Quit window
R Reset plot scale
S Show summary report
T Display original time-series
X Export data
Z Display clone of one panel

Some of these options are also available from pull-down menus: see File and Help at the top of the window.

These mouse and keyboard options are typical of plots generated by Jeda. However they are not all guaranteed to be implemented, nor are plot options limited to these. Type 'H' to see what options are available in any given case.

Scoring epoched data

To top At present there are only simple scoring options available, e.g. 'TradERP', 'TradSpect', 'HeartRate'. However it is intended that all manner of scoring and transformation options should be available: there might be options involving spatio-temporal wave decomposition, model fitting, single-trial analysis, variability (using the method of Riera-Diaz et al. (1995) in Int. J. Biomedical Computing, 38(2):109–120), etc. It should be easy to implement and test new scoring techniques since the hurdles of format incompatibilities and epoch extraction have been taken care of.

A typical example of command line invocation of scoring is 

    -score "TradERP(paraCond=OddbTg, years=40)[][Tg]"
In this case the chosen scoring method is TradERP. This method has several possible arguments, of which only paraCond and years are specified. The first informs the algorithm that it should presume the data to be Tg averages from an Oddball paradigm — this implies a certain set of components and typical latencies. The second argument further fine-tunes the assumed latencies. Arguments all have default values, so values need to be specified only the defaults are to be over-ridden.

Following the arguments is an (optional) specification of which boxes are to be scored. We might have the situation that the data is an array of 3 rows (alpha is weak medium or strong) × 2 columns (stimulus is Bg or Tg) boxes, each containing multiple waveforms. Then appending [][Tg], as in the example above, would mean that only the 'Tg' column of three boxes is scored. The square brackets may contain lists, so that (in this example) [weak,strong][Tg] would cause only two of the six boxes to be scored.

Running a 'scoring' plug-in causes the correspondingly-named Java class to be compiled and run; and that Java class can do anything whatsoever with the time-series data — including modifying it. This allows for transformations of the epoched data, as when ICA is carried out.

Any number of scoring plug-ins can be specified after -score on the command line, and they will be executed in the specified order. Thus, for example, the first might perform ICA, the second might sort and select relevant components, and the third might generate summary scores.

Scoring classes can call legacy code or scripts written in languages other than Java. This greatly complicates installation and restricts the portability of the code, but is a real-world requirement. One example is the scoring option EegFit() which calls a spectral-fitting routine written in C. Another example is CallR(), which enables an R script to operate on the data. Scripts written in R or Matlab etc. need to be placed in (or under) the directory scripts/score (or scripts\score in Windows): 

        scripts/score
        `-- test.R

Displaying epoched data

To top Graphical representations of the data can be displayed in their own interactive window. The way of invoking a particular display option is very similar to that of scoring options, e.g. 
 -display "TiledStack(sizeH=0.5, offsetV=0.15, offsetH=0.25, sizeV=0.8)"
It consists of the name of the option ('TiledStack'), four argument=value pairs (all optional), and an optional selection of rows and columns (e.g. [weak,strong][]). The arguments currently just specify the width, height and location of the plot window with respect to the top-left of the screen. Row and column selection is useful for eliminating those that are calculated and scored, but do not need to be displayed.

Graphic of epoched data

Discriminant factors cause the window to be divided into a number of plot areas, as illustrated in the above figure. Of course plotting stacked time-series is just one possibility. The plug-in 'TiledStack' is adequate for many purposes (it works for spectra too.) There are other ideas for display plug-ins:

In the case of 'TiledStack', each box contains stacked waveforms that can be manipulated as described under Viewing continuous time-series.

As an example, consider the scenario of a waveforms distinguished by 3 (site={Fz,Cz,Pz}) × 2 (face={neutral,happy}) × 2 (SCR={yes,no}) factors.

  1. Selecting `site' as the discriminant within each frame (by -binZ site) and `face' as the horizontal discriminant (by -binH face), will result in 'neutral' Fz,Cz,Pz waveforms plotted in the first frame, and 'happy' Fz,Cz,Pz waveforms plotted in the second.
  2. Specifying SCR as an additional discriminant (by -binV SCR) will cause there to be two rows of boxes instead of one.
  3. Turn on Standard Error in the Mean (press 'E') to see if the difference looks significant.

Scores (as described in Scoring epoched data) are automatically superimposed on plots.

Export in various textual formats

Exporting of waveform data and scores is implemented as just another display option. The full version of the export option (showing all arguments and their default values) is 

 -output "Export(to=FILE, baseFilename=out, as=TXT, tableSep=comma, tableAsCols=true, gui=false, outAttr=true, outWave=true, outStdD=false, outScor=true)"
As with all score and display options, this can be followed by box selectors (e.g. [SCR,noSCR][H,S,F,A,D]) or nothing (in which case all boxes will be exported). The following table explains the arguments, and their options.
Export argumentOption DescriptionDefault
to[FILE | WINDOW] Destination for outputFILE
baseFilenamefilename Name of output file (only if 'to=FILE'). Alphanumerics and the characters '.' '/' '\' are allowed; however '~' does not work. out
as[MATLAB | OBJ | R | SQL | TXT | XML] Format of outputTXT
tableSep[comma | space | tab] Field separator (only if 'as=TXT')comma
tableAsCols[true | false] Orientation (only if 'as=TXT')true
gui[true | false] Activate GUI, for an interactive experience false
valZ[ | Cz | SCL | ... ] Whether or what to drill-down to single trials
outAttr[true | false] Include attributes in outputtrue
outWave[true | false] Include attributes in outputtrue
outStdD[true | false] Include attributes in outputfalse
outScor[true | false] Include attributes in outputtrue
The various contingencies mean that there are four possible patterns: 
   # Plain format, output to a file
   Export(to=FILE, baseFilename=../blah3, as=TXT,
          tableSep=[comma|space|tab], tableAsCols=[true|false], 
          outAttr=[true|false], outWave=[true|false],
          outStdD=[true|false], outScor=[true|false])
   # Plain format, output to a window
   Export(to=WINDOW, as=TXT,
          tableSep=[comma|space|tab], tableAsCols=[true|false], 
          outAttr=[true|false], outWave=[true|false],
          outStdD=[true|false], outScor=[true|false])
   # Fancy format, output to a file
   Export(to=FILE, baseFilename=../blah3, as=[MATLAB|OBJ|R|SQL|XML],
          outAttr=[true|false], outWave=[true|false],
          outStdD=[true|false], outScor=[true|false])
   # Fancy format, output to a window
   Export(to=WINDOW, as=[MATLAB|OBJ|R|SQL|XML],
          outAttr=[true|false], outWave=[true|false],
          outStdD=[true|false], outScor=[true|false])

Remember that option names (e.g. 'Export') and arguments name (e.g. 'baseFilename') are case sensitive, but argument values (e.g. 'true') are not.

Each export file or window corresponds to one displayed box of waveforms, and so the same attributes that distinguish the boxes are used to distinguish the files/windows. Thus if the Export command specified baseFilename=../results/subj1028, and as=MATLAB, and if the box selectors are like [SCR,noSCR][H,S,F], then six files will be created: 

   ./results/subj1028.SCR.H.m   
   ./results/subj1028.SCR.S.m   
   ./results/subj1028.SCR.F.m   
   ./results/subj1028.noSCR.H.m
   ./results/subj1028.noSCR.S.m
   ./results/subj1028.noSCR.F.m

TXT is the most familiar of all the output formats, and its output is easiest for humans to read. However that is rarely the point of the exercise, and the other alternatives should be considered. MATLAB and R are good if futher waveform manipulation and display are contemplated. SQL and XML are good if generic persistence is required. Other output formats may be implemented in time, e.g. ARFF which is tailored for data mining using Weka, Mondrian, GGobi, or Rattle. Excel .xls format is a possiblity, with the help of Jakarta POI.

One of the neat things about the MATLAB and R options is that the data can be dumped together with appropriate display/analysis code in those languages. Using this code as a template means that the transition to analysis and plotting is easy.

Export directly to MySQL

Another display option provides for direct export to a MySQL database: 

   -output "DBExport(gui=false, dbName=br2008a001, baseTableName=results, outStdD=false, outWave=false, outScor=true, outAttr=false)"
As with all display options, the above command can be followed by box selectors.

Command line examples

To top Command line options are described above, and other matters to do with the OS environment are described under Running. Generally, however, it is possible to run the program with 
   java java_options frontendClasses.CLI application_options
where java_options commonly specifies a classpath and library locations, and will be similar to one of 
    java -cp build:lib/derby.jar:jri/JRI.jar -Djava.library.path=native:jri -Xmx300m frontendClasses.CLI application_options
    java -cp build;lib\derby.jar;jri\JRI.jar;%JAVA_HOME%\lib\tools.jar -Djava.library.path=native:jri -Xmx300m frontendClasses.CLI application_options
(Linux and Windows versions, respectively). The classpath should certainly include 'build;lib\derby.jar' and '%JAVA_HOME%\lib\tools.jar' (Windows only), however additional Java options are required only in certain (obvious) circumstances.

The remainder of the command line, application_options, can be quite varied, as described above. Some examples follow:

General instructions [Screenshot] 
   -h

Specific examples [Screenshot] 
   -eg

Create artificial data, display time-series, and write [Screenshot] 
  -scriptChannel mock_ec/DualAlpha -paradigm ec -reviewSeries -binZ Site -dumpBinned -display "TiledStack(offsetV=0.1, offsetH=0.25, sizeH=0.3, sizeV=0.15)"

Read and view data in its most raw form [Screenshot] 
  -fn data/17000356.ODDB.NS5 -scriptChannel Minimal -paradigm oddb -reviewSeries

Read EC data, av reference, display time-series, and write raw [Screenshot] 
  -fn data/10006636.EC.NS5 -scriptChannel Standard:AvRef -paradigm ec -scriptEpoch OneLong -chanSelection "Site like '_z'" -reviewSeries -dumpUnbinned

Read oddball data, bin by RTclass x Stim x Site, show fast/slow targets [Screenshot] 
  -fn data/17000356.ODDB.NS5 -paradigm oddb -eventSelection "Stim like '_g'" -chanSelection "Site like '_z'" -binV RTclass -binH Stim -binZ Site  -score "TradERP()[][Tg]" -display "TiledStack(sizeH=0.3, sizeV=0.6)[slowrt,fastrt][Tg]"

Read Oddball data, display time-series, and plot Bg and Tg averages [Screenshot] 
  -fn data/17000356.ODDB.NS5 -paradigm oddb -eventSelection "Stim like '_g'" -chanSelection "not Mode='EVE'" -binV AlphaQ -binH Stim -binZ Site -score "TradERP(years=22,paraCond=OddbTg)[][Tg]" "TradERP(years=22,paraCond=OddbBg)[][Bg]" -display "TiledStack(offsetV=0.1, offsetH=0.25)" -output "Export(as=R,to=window)"

EC spectral plots [Screenshot] 
  -fn data/10006636.EC.NS5 -paradigm ec -eventSelection "Stim='Pseudo'" -chanSelection "Mode='EEG'" -transform power -binZ Site -score "TradSpect()" -display "TiledStack(offsetV=0.2, offsetH=0.25)"

Dump entire time series to a file 
  -fn data/10006636.ODDB.NS5 -paradigm ec -scriptEpoch OneLong -chanSelection "Mode='EEG' OR Mode='ECG'" -binZ Site -score "HeartRate()" -output "Export(to=FILE, baseFilename=out, outScor=true)"

The above commands are routinely used during development to test the program. They also illustrate how effective the overall design is at reducing a lot of complications to a manageable number of command line options. In particular they demonstrate how the intricacies of filtering, re-referencing, and event refinement can be hidden in scripts: see the examples listed under Time-series operations and Epoch selection.

Note about formatting. Spaces, brackets and quotes have special meanings to the shell interpreter, and can cause the program to 'see' something other than what you type on the command line. This is a useful feature in general, but can be an annoyance if the process is not understood. Some useful clues to composing commands are:

 

Validate HTML CSS Last changed 2010-01-06 Chris Rennie