What’s new in version 0.6.x#

Version 0.6.x (released in July 2022) is the biggest update in the GUI’s history, with a number of changes designed to make the GUI more efficient and easier to use. This page explains some of the major updates in this release, to help you get up and running faster.

Stream-based processing#

The most important change in version 0.6.x is that channels are now organized by “streams,” which represent a group of continuous channels that are sampled synchronously. Previously, synchronously sampled channels were grouped together into “subprocessors,” but there was minimal information available about subprocessors, and settings were still applied on a channel-by-channel basis. Now, each plugin includes a “stream selector” interface that replaces the old “channel selector” interface:

Channel selector vs stream selector

When a signal chain includes multiple streams (e.g., when using multiple Neuropixels probes, or multiple sources merged together), the user can browse through the streams that pass through downstream plugins and apply settings on a per-stream basis. For example, this makes it possible to have a separate Common Average Reference for each stream. The stream selector interface also includes a visualization of the state of all TTL lines for a given stream, as well as the overall processing delay introduced by the signal chain.

Default configurations#

The first time the GUI is launched (or after selecting “Load a default config” from the File menu), the user has the option to choose from up to three different default configurations:

  1. Acq. Board - Streams data from the Open Ephys acquisition board (if available).

  2. File Reader - Streams data from a file (useful if no acquisition hardware is available).

  3. Neuropixels (Windows only) - Streams data from one or more Neuropixels PXI basestations.

Fewer built-in plugins#

In version 0.6.x, a number of plugins that were previously included by default have been moved to separate repositories. This includes the “Rhythm FPGA” plugin (now split in two and renamed “Acqusition Board” and “Intan RHD USB”), the Spike Sorter, and the Pulse Pal. Moving these plugins to their own repositories makes it possible to upgrade them via the Plugin Installer, instead of having to update the entire host application.

Audio Monitor plugin#

Previously, each plugin’s editor had an “AUDIO” tab that made it possible to select channels to monitor. Now, all audio monitoring is configured via a dedicated plugin, found under the “Utilities” section of the Processor List. The advantage of using a separate Audio Monitor plugin is that it makes it easier to track the selected channels, and also adds a built-in bandpass filter, so the monitored signals sound good no matter where in the signal chain you’re listening to them:

Audio monitor plugin

The only restriction is that the Audio Monitor must be placed in the middle of the signal chain, rather than at the very end. The Audio Monitor does not affect any of the data that passes through it.

Event Translator plugin#

Events generated by one stream can now be copied to other streams, provided that all streams share a signal on at least one hardware TTL line. The Event Translator plugin will use this shared signal to automatically compute the offset and scaling factor required to translate events across streams with unique sample clocks. Then, downstream plugins can access events generated across a different stream. These events can be used by the LFP Viewer in triggered display mode, or the Online PSTH.

Consistent naming and numbering conventions#

In previous versions of the GUI, the word “timestamp” would sometimes refer to actual times in seconds, but could also refer to sample numbers since the start of acquisition. To remove this ambiguity, “timestamp” now refers exclusively to global times in seconds (floating point values), while “sample number” is used for counting samples from an individual data source (integer values). This change has been implemented throughout the source code, as well as in the data files. This may cause some confusion, as the Binary Format previously saved sample numbers in the timestamps.npy file. Now, timestamps.npy stores globally synchronized timestamps from a given Record Node, while sample_numbers.npy stores the local sample numbers for each source.

The naming conventions around events have also changed. An event “channel” produces samples at irregularly spaced intervals within single data stream, similar to how a continuous channel generates samples at regularly spaced intervals within one stream. Each processor can have multiple event channels to represent different types of events. However, it’s most common for processors that produce events to have one “TTL channel” per stream. TTL channels are a special type of event channel that can specify the state of one or more “lines” that can either be “ON” or “OFF”. To avoid ambiguity, the Binary Format now stores the state of each TTL line in states.npy rather than channel_states.npy.

In addition, we are now stricter about adhering to the convention that user-facing numbering should use 1-based indexing, while the software uses 0-based indexing under the hood (including in configuration files). Most people prefer to see channel and line numbers that start at 1, whereas C++ operations usually assume numbering starts at 0.

Settings file format#

The XML files that store the state of the Open Ephys signal chain are now much more compact and easier to read. Instead of storing the state of every single channel, they only include the minimal amount of information required to reproduce the signal chain. Because the settings file format has changed substantially, settings files saved by GUI version 0.5.x and lower cannot be opened by version 0.6.x.

Built-in HTTP server#

Remote control of the GUI’s state was previously handled by the Network Events plugin, which had to be installed separately from the host application. Now, the GUI automatically runs a Remote control server that listens for commands on port 37497 (EPHYS on a phone keypad). This can be used to get information about the current signal chain, change the recording directory, and start/stop acquisition and recording, among other things.

The API is “RESTful”, such that the resource URLs are:

  • GET /api/status : returns a JSON string with the GUI’s current mode (IDLE, ACQUIRE, RECORD).

  • PUT /api/status : sets the GUI’s mode, e.g.: {"mode" : "ACQUIRE"}.

  • PUT /api/message : sends a broadcast message to all processors while acquisition is active, e.g.: {"text" : "Message content"}.

  • GET /api/processors : returns a JSON string with information about the GUI’s signal chain.

  • PUT /api/processors/<processor_id>/config : sends a configuration message to one processor, e.g.: {"text" : "Message content"}.

  • GET /api/recording` : returns a JSON string with information about recording parameters, including the IDs of the available Record Nodes.

  • PUT /api/recording : used to set the default recording options.

  • PUT /api/recording/<processor_id>` : used to set the options for a given Record Node.