BCI2000 Wiki - New pages [en]

Contributions:ScreenCaptureLogger

2026-05-06T15:01:01Z

Mellinger: /* ScreenCaptureAreas */

==Synopsis==
An extension that records video from one or more screen areas to mp4 files, and stores frame numbers as (event-type) state variables.

==Location==
http://{{SERVERNAME}}/svn/trunk/src/contrib/Extensions/ScreenCaptureLogger<br>
http://{{SERVERNAME}}/svn/trunk/src/contrib/Extensions/ScreenCaptureLogger_Wayland

==Versioning==
===Authors===
Juergen Mellinger (mellinger@neurotechcenter.org)

===Version History===
May 6, 2026: initial version

===Source Code Revisions===
*Initial development: 9343
*Tested under: 9357
*Known to compile under: 9357

===Known Issues===
On Linux, the Wayland version has never been working. It connects to the XDG screen capturing portal and displays a screen selector dialog but subsequently fails to establish a connection to the PipeWire daemon. Due to lack of error information and documentation on the PipeWire side, it is currently not possible to fix the issue with reasonable effort.

==Functional Description==
For many experiments, a documentation of screen content is desired. While the content of the user's task window is available in the ApplicationWindow visualization, this has its limitations, especially if the participant's screen is not displayed by a BCI2000 application module but a third party stimulus presentation kit such as ''PsychoPy'' or ''PsychToolBox''.

This extension allows capturing of any number of desktop areas, and saving each into its own MP4 video file. It also records the current frame number as a state variable, so that the video can be synchronized with brain data at sample resolution (max. 1ms).

The video file bears the name of the BCI2000 data file, with the extension removed and <tt>_ScreenCaptureM.mp4</tt> appended where <tt>M</tt> is the one-based index of the screen area in question.
For the format of the video file, see [[Contributions:ScreenCaptureLogger#Format_of_the_Video_File|the notes below]].

==Integration into BCI2000==
Compile the extension into your source module by enabling contributed extensions in your CMake configuration. In your root build folder, run <tt>Configure.sh.cmd</tt> in order to bring up the CMake GUI; there, enable EXTENSIONS_SCREENCAPTURELOGGER for the Windows/macOS/Linux-X11 version of the module.
In order to use the Linux-Wayland version '''disable''' EXTENSIONS_SCREENCAPTURELOGGER, and '''enable''' EXTENSIONS_SCREENCAPTURELOGGER_WAYLAND.
You cannot enable both the default and the Wayland version.

Further requirements are:
===Windows===
No further requirements must be met.
===macOS===
On macOS, the extension requires at least macOS 15.2 (Sequoia) to compile and run.
===Linux-X11===
The X11 version of the extension requires the xcb (X11 C bindings) and the xcb-shm (XCB shared memory extension) libraries and headers. On Debian-based distributions, this resolved by installing the ''libxcb-dev'' and ''libxcd-shm0-dev'' packages. On other distributions, installing ''libxcb'' may be sufficient.
===Linux-Wayland===
To build the (currently broken) Wayland version of the extension, it its necessary to install the sdbus-c++ library (''libsdbus-c++-dev'' on Debian-based systems, ''sdbus-cpp'' on Arch) as well as the PipeWire library (''libpipewire-dev'' on Debian-based distributions, ''libpipewire'' on Arch).

Once the extension is built into the source module, enable it by starting the source module with the <code>--LogScreenCapture=1</code> command line argument.

==Parameters==
The ScreenCapture logger is configured in the ''Source'' tab within the ScreenCaptureLogger section. The configurable parameters are:

===LogScreenCapture===
Enables/Disables the logger extension.
===DisplayCaptureStream===
Display the video stream from each captured screen area. Display stream is identical to what is being recorded in the .mp4 file.
===ScreenCaptureAreas===
A matrix parameter with each row representing an independently capture area (capture areas may overlap).
In each row, you may specify a video width, height, spatial decimation, fps, encoder profile, and a compression factor.
The ''encoding profile'' column allows you to choose an H.264 encoding profile for video output, which may be a number from 1 to 3. '''1''' corresponds to the "baseline" profile, '''2''' corresponds to the "main" profile, and '''3''' corresponds to the "high" profile as defined in the ''ITU-T H.264'' standard.
If the encoder uses ffmpeg’s ''x264'' codec (on non-Windows systems), the additional option ''tune=animation'' is applied to optimize encoding for screen content. On Windows, the ''mf_h264'' codec is used which does not provide such an option.

The ''compression factor'' determines the amount of data compression applied when encoding the stream of images into an .mp4 file. The smallest possible compression setting is 1 (no compression). Use a setting of 100 to compress the data stream to 1/100 of its original size.

==Event Variables==

===ScreenCaptureFrame<1-n>===
The frame number of the screen capture area with row i. The default value of n is 4, allowing for capturing of up to 4 areas. To record more areas, change the <code>NUM_OF_SCREEN_CAPTURE_EVENTS</code> macro in ScreenCaptureLogger.cpp to the number of areas you want to record, and recompile. Event values can be used to synchronize the video with the recorded neural data. It is a 32-bit value, allowing 4294967295 frames before overflowing. If screen capturing is done at 30 frames/sec, this allows more than four years of video before it will go back to frame 0. In other words, this should not be an issue for most users.

==Format of the Video File==
Each capture area writes its own video file. Files in mp4 format (and related formats) do not allow to seek to locations that represent original frames when writing the file. Rather, the file's nominal frame rate and length are used in conjunction with interpolation to construct a frame at an ideal location.
Thus, it is not possible to write individual frames using the screen capture’s original timestamp, at the original frame rate.

Instead, the file is written with the nominal framerate specified in the ''fps'' column of the ''ScreenCaptureAreas'' parameter, with differences between frame timestamps matching ideal frame duration.
This way, loading the video into e.g. Matlab, you will obtain a sequence of frames where each frame index corresponds to the frame index in the <tt>ScreenCaptureFrameN</tt> state (minus 1).

For a strategy how to synchronize video file frames with brain signal data, and possibly audio data, see [[User_Reference:BCI2000Viewer#AV_Synchronization_Strategies|this page]].

==See also==
[[User Reference:Logging Input]], [[Contributions:Extensions]], [[Programming Reference:Events]], [[User Reference:BCI2000Viewer]]

[[Category:Contributions]][[Category:Extension]]

Contributions:AVStreamingTask

2026-04-10T13:24:12Z

Mellinger: /* Example Batch File */

==Synopsis==
This extension displays video from a remote location, plus local video in a user application window.
It works in conjunction with the ''SimpleRelayServer'' application running within a local network, or on the internet.
Audio may be transferred in one direction as well. Bidirectional audio is possible but will lead to feedback unless earphones are used.

===Authors===
Jürgen Mellinger (mellinger@neurotechcenter.org)

==SimpleRelayServer==
To allow connection between machines which are located at different locations, and possibly in different local networks,
it is necessary to use a bridge that is accessible to both machines.
AVMeetingExtension is designed to use a relay server for this bridge.
In order to bridge different local networks, the relay server must be located somewhere in the open internet, on a Linux server under the experimenter's control.

Follow these steps to build and run the necessary ''SimpleRelayServer'' executable on a Linux machine:
* Download <tt>SimpleRelayServer.cpp</tt> from
https://bci2000.org/svn/trunk/src/contrib/Extensions/AVMeetingExtension/SimpleRelayServer/SimpleRelayServer.cpp
* cd to the download's directory and execute
g++ SimpleRelayServer.cpp -o SimpleRelayServer
* Start the server with
./SimpleRelayServer 2>/dev/null
or just
./SimpleRelayServer
if you want to see log messages on the console.
By default, the server process will listen on all of the machine's interfaces, at port 1915.
A different port may be specified by providing a command line argument:
./SimpleRelayServer 1928 2>/dev/null

'''NOTE:''' For testing purposes, BCI2000 provides a SimpleRelayServer instance at <tt>upload.bci2000.org:1915</tt>.

==Example Batch File==
The following example batch file starts up BCI2000 with the ''SignalGenerator'' source module, the ''DummySignalProcessing'' module, and the ''GuiltTask'' with the ''AVMeetingExtension'' enabled.
<pre>
#! ../prog/BCI2000Shell
@cls & ..\prog\BCI2000Shell %0 %* #! && exit /b 0 || exit /b 1\n

Change directory $BCI2000LAUNCHDIR
Show window; Set title ${Extract file base $0}
Reset system
Startup system localhost
Start executable SignalGenerator --local --LogKeyboard=1
Start executable DummySignalProcessing --local
Start executable GuiltTask --local --EnableAVMeeting=1 --Port=1234 --IPAddress=3.216.172.59 --SharedStates=isReadyStart0,8&isReadyStart1,8&ClientNumber,8&CompensationTrans,32&CompensationVictim,32
Wait for Connected

Load parameterfile "../parms/GuiltTask/guiltTaskLocal.prm"

</pre>

==Parameters==
===EnableAVMeeting===
If nonzero, enables the AVMeeting extension.

===StreamingServer===
The streaming server's address with port, as in ''upload.bci2000.org:1915''. This must match the ''SimpleRelayServer's'' listening address.
For testing purposes, an instance of the streaming server is running at the BCI2000 server's address given above.

===CameraIndex===
The local camera's 0-based index into the video backend's list of detected cameras. Typically 0 unless multiple cameras are attached.
A value of -1 disables video streaming.

===AudioDeviceIndex===
The local audio input device's 0-based index into the audio backend's list of detected audio devices.
Specify -1 to disable audio streaming from the local machine.

===VideoEncoder===
The name of the desired video encoder to use, e.g. h264_mf or libx264.
Specify ''auto'' to use h264_mf on Windows, and libx264 on non-Windows systems.

===RemoteVideoRect===
The display rectangle for remote video, in relative coordinates. Values are ''left'', ''top'', ''bottom'', ''right''. Defaults to <tt>0 0 1 1</tt>, i.e. the entire window.

===RemoteVideoZ===
The remote video display's Z coordinate. Objects with a smaller Z coordinate are displayed on top objects with larger Z coordinates.

===RemoteVideoVisibility===
A BCI2000 expression which may entail BCI2000 state names. Whenever this expression evaluates to a nonzero value, remote video is displayed.
Otherwise, remote video is hidden.

===LocalVideoRect===
The display rectangle for local video, in relative coordinates. Values are ''left'', ''top'', ''bottom'', ''right''. Defaults to <tt>0.75 0 1 0.25</tt>, i.e. the upper right corner of the display window.

===LocalVideoZ===
The local video display's Z coordinate. Objects with a smaller Z coordinate are displayed on top objects with larger Z coordinates.

Note that by default the local video rectangle overlaps with the remote video rectangle, and local video is on top of the remote.

===LocalVideoVisibility===
A BCI2000 expression which may entail BCI2000 state names. Whenever this expression evaluates to a nonzero value, local video is displayed.
Otherwise, local video is hidden.

==States==

===VideoStreamingLocalTotalFrames===
A 32-bit state holding the current local frame number since the beginning of the current recording (BCI2000 run).

===VideoStreamingRemoteTotalFrames===
A 32-bit state holding the current remote frame number since the beginning of the current recording (BCI2000 run).

===VideoStreamingLocalFrame===
A 32-bit state holding the current local frame number since the beginning of the current file.

===VideoStreamingRemoteFrame===
A 32-bit state holding the current remote frame number since the beginning of the current file.

==Files==
Both local and remote video is being recorded into files in mp4 format.
These files bear the current BCI2000 file's basename, followed with <tt>_VideoStreamingLocal</tt> and
<tt>_VideoStreamingRemote</tt>, respectively.

'''NOTE:''' Seeking to individual frames is not possible for mp4 files unless frame time stamps exactly match the frame rate specified at the beginning of the file. To work around this, video files are created with the camera's nominal frame rate, and artificial time stamps proportional to frame number are used when writing frames to a file.
In analysis, it will be possible to reconstruct actual time stamps using one of the frame count states.

However, replaying mp4 files written by the ''AVMeetingExtension'' with a standard video player may not result in proper playback speed.

==See also==
[[Contributions:Extensions]]

[[Category:Contributions]]

Programming Reference:SignalSharingClientLibDemo

2026-03-12T16:00:19Z

Mellinger: /* Client application code */

==Location==
<tt>src/core/SignalProcessing/SignalSharingDemo/CppLibraryClient</tt>

==Synopsis==
The ''SignalSharingClientLibDemo'' client demonstrates how to receive signal data from BCI2000, using the [[Technical Reference:SignalSharingClient Library|SignalSharingClient Library]].
SignalSharing allows to tap into BCI2000 processing by receiving any filter output signal through a combination of a TCP connection, and shared memory.

==Function==
The ''SignalSharing'' component in BCI2000 shares its input signal through a <tt>GenericSignal</tt> object which has been linked to a shared memory block using <tt>GenericSignal::ShareAcrossModules()</tt>. A dedicated thread waits for signal updates, and sends signal data out to a separate application waiting on a TCP/IP connection.

When the client application is running on a separate machine, full signal data are sent over the network. When the client is running on the same machine, only a reference to a shared memory block is sent. On the application side, unserializing the signal will transparently bind it to the shared memory block if available.

The simple client application receives BCI2000 parameters and data blocks, and writes them into a parameter file, and a signal file.

==Client application code==
The client application uses the [[Technical Reference:SignalSharingClient Library|SignalSharingClient Library]] to receive data from BCI2000. This way, it does not have to deal with BCI2000 messages but will see the raw data directly. The [[Technical Reference:SignalSharingClient Library|SignalSharingClient Library]] is contained in the file <tt>prog/SignalSharingClientLib.dll</tt> for Windows, and carrying the appropriate file extension for shared libraries on other platforms. For convenience, header file and <tt>.lib</tt> file (if any) are also located at <tt>prog</tt>.

The simple example consists of a single source file.

Note how the callback functions call the appropriate <tt>SSC_Lock*()</tt> function, followed with processing of the data, and calling <tt>SSC_Release*()</tt> as soon as possible. Also note that care is taken to call <tt>SSC_Release*()</tt> only if the call to <tt>SSC_Lock*()</tt> was successful.

Similarly, note how <tt>main()</tt> calls <tt>SSC_DeleteConnector()</tt> no matter whether an exception occurred or not.

To avoid clutter, and throw an exception when an unexpected error has occurred, we define a <tt>SSC_SucceedOrThrow</tt> class that can be used in place of a plain numeric variable to hold a function's return value.
Note how exceptions are caught in the <tt>main()</tt> function before calling the <tt>SSC_DeleteConnector()</tt> function. This is possible because <tt>SSC_CreateConnector()</tt> guarantees to null the resulting handle if any error occurs. This implies that we can call <tt>SSC_DeleteConnector()</tt> without using a dangling or otherwise invalid pointer.

<syntaxhighlight lang="cpp">
#include "SignalSharingClientLib.h"

#include <iostream>
#include <fstream>
#include <string>
#include <mutex>

static std::string SSC_ResultToString(SSC_RESULT result)
{
switch (result) {
case SSC_SUCCESS:
return "Success";
case SSC_INVALID_ARG:
return "Invalid argument";
case SSC_CANNOT_LISTEN:
return "Cannot listen on given address";
case SSC_CANNOT_FULFILL_REQUEST:
return "Cannot fulfill request at this time";
}
return "Unknown error";
}

// Translate an error code into an exception
struct SSC_SucceedOrThrow
{
SSC_SucceedOrThrow(SSC_RESULT result)
{
if (result != SSC_SUCCESS) {
throw std::runtime_error(SSC_ResultToString(result));
}
}
};

// The data we need inside the callback functions
struct ConnectorData
{
SSC_HANDLE h = nullptr;
std::ofstream paramfile, datafile;
std::mutex mutex;
};

// Callback function for handling parameters
static void HandleParameters(void* pData)
{
std::cout << "Received parameters ..." << std::endl;
auto pConnectorData = static_cast<ConnectorData*>(pData);
const char* const* parameterLines = nullptr;
int count = 0;
if (SSC_SUCCESS == ::SSC_LockParameters(pConnectorData->h, &parameterLines, &count)) {
std::unique_lock lock(pConnectorData->mutex);
for (int i = 0; i < count; ++i) {
pConnectorData->paramfile << parameterLines[i] << "\n";
}
lock.unlock();
::SSC_ReleaseParameters(pConnectorData->h);
}
}

// Callback function for handling signals
static void HandleSignal(void* pData)
{
std::cout << "Received signal ..." << std::endl;
auto pConnectorData = static_cast<ConnectorData*>(pData);
union { const double* d; const char* c; } pSignal = { nullptr };
int channels = 0, samples = 0;
if (SSC_SUCCESS == ::SSC_LockSignal(pConnectorData->h, &pSignal.d, &channels, &samples, nullptr)) {
std::unique_lock lock(pConnectorData->mutex);
// Transpose data so we have a continuous stream of samples across channels
for (int sample = 0; sample < samples; ++sample) {
for (int ch = 0; ch < channels; ++ch) {
// Data comes in channel-major format
int idx = ch * samples + sample;
pConnectorData->datafile.write(pSignal.c + idx * sizeof(double), sizeof(double));
}
}
lock.unlock();
::SSC_ReleaseSignal(pConnectorData->h);
}
}

int main(int argc, char **argv)
{
std::string address = "localhost:1879";
if (argc > 1)
address = argv[1];

std::string paramfile = "sscparams.prm";
if (argc > 2)
paramfile = argv[2];

std::string datafile = "sscdata.raw";
if (argc > 3)
datafile = argv[3];

// The main function's return value
int result = 0;

ConnectorData data;
// Callback functions are called from a separate thread, so let's lock the mutex
// (not really necessary here because the thread will first start inside SSC_CreateConnector() below)
std::unique_lock lock(data.mutex);
data.paramfile.open(paramfile);
data.datafile.open(datafile, std::ios::binary | std::ios::out);
lock.unlock();
try {
SSC_SucceedOrThrow result = ::SSC_CreateConnector(address.c_str(), &data.h);
result = ::SSC_RegisterParametersCallback(data.h, &HandleParameters, &data);
result = ::SSC_RegisterSignalCallback(data.h, &HandleSignal, &data);

// Callback functions are called from a separate thread, so just wait for user input
std::cout << "Press <Enter> to quit" << std::endl;
std::string ignored;
std::getline(std::cin, ignored);
}
catch (const std::exception& exc) {
std::cerr << "Error: " << exc.what() << std::endl;
result = -1;
}
::SSC_DeleteConnector(data.h);
return result;
}
</syntaxhighlight>

==Parameters==
===ShareTransmissionFilter===
IP address and port number of the client application. The client's default address is <tt>localhost:1879</tt> but may be changed on the client's command line.

The example uses the ''ShareTransmissionFilter'' parameter but any other filter's ''Share<FilterName>'' parameter under the ''SignalSharing'' tab will work as well to visualize the chosen filter's output signal.

==See also==
[[User Reference:SignalSharing]], [[Programming Reference:GenericSignal Class]], [[Programming Reference:SignalSharing Python Demo]], [[Programming Reference:SignalSharingClientLibDemo]]

[[Category:Framework API]][[Category:Howto]][[Category:Development]]

Technical Reference:SignalSharingClient Library

2026-03-11T14:07:49Z

Mellinger: /* SSC_RESULT SSC_DeleteConnector(SSC_HANDLE) */

The SignalSharingClient library provides a [[User Reference:SignalSharing|SignalSharing]] client, wrapped into a C interface. It may be used to tap into signal and state data at any point of processing from external applications. The SignalSharingClient library can be used from any programming language that allows using a shared library (DLL). Although the SignalSharingClient library is written in C++, its DLL interface is plain C, and can be used with compiled languages such as C, C++, C#, Pascal, but also with interpreted languages that can call functions in a DLL, such as Python, Matlab, VisualBasic, etc. Interfacing with Java requires a JNI (Java Native Interface) wrapper, which is currently not provided by BCI2000.

==Functions provided by the Library==

===SSC_RESULT SSC_CreateConnector(const char* listeningAddress, SSC_HANDLE*)===
Create a connector object, and obtain a handle to it. A connector object is necessary to handle a connection to BCI2000,
and is specified as the first argument of the remaining ''SignalSharingClient'' library functions.
The listening address is in the format <IP>:<port> with <IP> being a name or numeric address.
<tt>SSC_CreateConnector()</tt> will immediately start an internal server thread, and listen at the given port.
Only one client can connect to the server at a time (note that BCI2000 acts as a client).

<tt>SSC_CreateConnector()</tt> guarantees that the handle it returns will be either a valid handle, or nullptr (if an error occurs).
This implies that <tt>SSC_DeleteConnector()</tt> may be called unconditionally on a handle returned by <tt>SSC_CreateConnector()</tt>.

===SSC_RESULT SSC_DeleteConnector(SSC_HANDLE)===
Stop listening, terminate the internal server thread, and delete the given connector object. Must be called when connector object is no longer used.

Providing a nullptr handle to <tt>SSC_DeleteConnector()</tt> will result in an <tt>SSC_INVALID_ARG</tt> error but will otherwise cause no harm.

===SSC_RESULT SSC_RegisterSignalCallback(SSC_HANDLE, SSC_CALLBACK, void* refdata)===
Register a callback to be called whenever new signal data is available.
For each connector object, it is only possible to register one signal callback at a time.
To unregister a signal callback, call <tt>SSC_RegisterSignalCallback()</tt> with a <tt>nullptr</tt> argument.
Use the <refdata> argument to specify auxiliary data which will be provided to the callback function when it is called.

===SSC_RESULT SSC_RegisterStatesCallback(SSC_HANDLE, SSC_CALLBACK, void* refdata)===
Register a callback to be called whenever new state data is available.
For each connector object, it is only possible to register one states callback at a time.
To unregister a signal callback, call <tt>SSC_RegisterStatesCallback()</tt> with a <tt>nullptr</tt> argument.
Use the <refdata> argument to specify auxiliary data which will be provided to the callback function when it is called.

===SSC_RESULT SSC_RegisterParametersCallback(SSC_HANDLE, SSC_CALLBACK, void* refdata)===
Register a callback to be called whenever new parameter data is available.
For each connector object, it is only possible to register one parameters callback at a time.
To unregister a signal callback, call <tt>SSC_RegisterParametersCallback()</tt> with a <tt>nullptr</tt> argument.
Use the <refdata> argument to specify auxiliary data which will be provided to the callback function when it is called.

===SSC_RESULT SSC_LockSignal(SSC_HANDLE, const double** pSignal, int* channels, int* samples, const char* const** channelNames)===
Lock signal data and obtain signal information. Typically, this function will be called from a signal callback.
Locking blocks the arrival of new signal data, so call <tt>SCC_ReleaseSignal()</tt> as soon as possible.
All pointer arguments are optional, may be <tt>nullptr</tt>.

The ''pSignal'' argument receives a pointer to an array in channel-major order, i.e. to compute a linear index into that array from both
channel and sample index, use
idx = channel * samples + sample

===SSC_RESULT SSC_ReleaseSignal(SSC_HANDLE)===
Releases a locked signal. Call this function as soon as you are done with forwarding or processing signal data.

===SSC_RESULT SSC_LockStates(SSC_HANDLE, const double** pStateData, int* count, int* samples, const char* const** pStateNames)===
Lock state data and obtain state information. Typically, this function will be called from a state callback.
Locking blocks the arrival of new state data, so call <tt>SCC_ReleaseStates()</tt> as soon as possible.
All pointer arguments are optional, may be <tt>nullptr</tt>.

The ''pStateData'' argument receives a pointer to an array in channel-major format, i.e. use the following formula to compute a linear index from state and sample index:
idx = state * samples + sample

===SSC_RESULT SSC_ReleaseStates(SSC_HANDLE)===
Releases locked state information. Call this function as soon as you are done with forwarding or processing state data.

===SSC_RESULT SSC_LockParameters(SSC_HANDLE, const char* const** parameterLines, int* count)===
Lock parameter data and obtain parameter information. Typically, this function will be called from a parameter callback.
Locking blocks the arrival of new parameter data, so call <tt>SCC_ReleaseParameters)</tt> as soon as possible.
All pointer arguments are optional, may be <tt>nullptr</tt>.

===SSC_RESULT SSC_ReleaseParameters(SSC_HANDLE)===
Releases locked parameter information. Call this function as soon as you are done with forwarding or processing parameter data.

===SSC_RESULT SSC_GetSignalDimensions(SSC_HANDLE, int* channels, int* samples)===
Obtain signal dimensions for use with <tt>SSC_PushSignal()</tt>.

===SSC_RESULT SSC_PushSignal(SSC_HANDLE, const double* pSignal)===
Push signal data to BCI2000. The ''pSignal'' pointer must point to a valid memory area that is at least as large as determined by a previous call to <tt>SSC_GetSignalDimensions</tt>. Pushing signal data will have no effect unless <tt>SSC_Commit()</tt> is called.

===SSC_RESULT SSC_PushState(SSC_HANDLE, const char* name, unsigned int value)===
Push a state value to BCI2000. Pushing a state value will have no effect unless <tt>SSC_Commit()</tt> is called.

===SSC_RESULT SSC_Commit(SSC_HANDLE)===
Commit pushed signal and state data to the BCI2000 pipeline. Any previously pushed signal or state data will be inserted into the BCI2000 pipeline when this function is called.

==Callback Function Type==
To be registered using <tt>SSC_Register*Callback()</tt>, a function must be a free (non-member) or static function, and have the following signature:
void MyCallback(void* refdata)
The ''refdata'' argument will hold the struct or object pointer specified as ''refdata'' when calling <tt>SSC_Register*Callback()</tt>.

==Error Codes==
All of the above functions return an error code of type <tt>SSC_ERROR</tt>.
The following codes are defined:
{|
| SSC_SUCCESS || The operation completed successfully.
|-
| SSC_INVALID_ARG || One or more of the function's arguments were invalid.
|-
| SSC_CANNOT_LISTEN || The connector was created but could not bind to/listen on the given address.
|-
| SSC_CANNOT_FULFILL_REQUEST || The connector is in a state in which it cannot fulfill the request, try again later.
|}

==See also==
[[Programming Reference:SignalSharingClientLibDemo]],
[[Technical Reference:BCI2000Remote Library]], [[Programming Reference:BCI2000Remote Class]], [[Contributions:BCI2000Command]], [[Contributions:BCI2000PresentationLink]], 
[[Contributions:Applications]]

[[Category:External Interfaces]][[Category:User Application]]