Starting with version 0.4.0 the GUI features a plugin architecture, allowing it to be expanded with external modules without the need to recompile it in its entirety the entire program every time a new feature is added. Currently, the GUI supports the following four types of plugins:

• Processor plugins. Allow the creation of processors for its placement These plugins are used to create processors that can be placed in the signal chain. This kind is the most extensive, as processors can be wither either sources, sinks, filters or utilities. A processor plugin can also be a visualizer, like the LfpViewer, and can feature custom editors and viewport components.
• DataThread plugins. This  These plugins are used by the SourceNode core processor to asynchronously access source data, usually from acquisition hardware, allowing you to implement controller nodes for multiple different hardware devices.
• RecordEngine plugins. Record Engines are the classes uses used by the record subsystem to store data in to disk. They allow you to define multiple new file formats for recording storing recorded data.
• FileSource plugins. The inverse of the Record Engines, this these plugins are used by the File Reader to load different file formats for data replay.

Overview

The main elements comprising of the plugin architecture are the library files, the Plugin Manager and the shared services that the GUI offers.

Library Files

Those Library files are the compiled binaries that contain the different plugins. A single library file can contain multiple plugins of different kinds, exporting a set of methods that allow the Plugin Manager in the GUI to inspect its contents and know how to instantiate the different plugins.

All library files are placed into a "plugins" folder located next to the binary executable and are loaded at startup. If the GUI console is active, it will show all the files it's trying to load, the result of the operation, and the number of plugins each library contains if load its succesful.

...

• The library must have been built against a version of the code with the same plugin API. Libraries contain a plugin API version field that is checked against the one of the running GUI, preventing load if and they will not be loaded unless the API do not versions match.
• The library must have been built for the same OS and with the same compiler as the GUI. Since the libraries make use of many C++ classes inside the GUI code and viceversa, both must be binary compatible, which means they must have been compiled by the same compiler must be used for two. Different versions of the same compiler might or might not be compatible between them, which so this should be tested on a case-by-case basis.

Plugin Manager

The PluginManager is the class responsible for loading and managing plugins. It maintains a list of all loaded libraries and the plugins they contains contain, and can be accessed via AcessClass to instantiate a specific plugin. It also provides search capabilities to be able to load plugins from signal chains generated in configurations with different available plugins.

...

In addition to the base classes from which the plugins are derived, the GUI offers a series of methods that allow interaction outside the scope of the plugin. Some examples are include: showing messages through the status bar, refreshing the signal chain, or starting/stopping acquisition or recording. All of these functions can be accessed through the CoreServices namespace, available to all plugins. All JUCE classes are also available for the plugins to use, and are exported through the GUI itself.

Creating plugins

Creating a plugin is a matter of involves creating the desired plugin classes, exporting the library info methods, and creating the required build files.

To ease plugin creation, all headers that might be needed by any plugin are located inside header files available at Source/Plugins/Headers. A plugin must not use headers outside the ones therein that directory. The available headers are:

• ProcessorHeaders.h contains all headers needed to create a Processor, which are derived from GenericProcessor.
• EditorHeaders.h contains all headers needed to create an Editor for a Processor plugin.
• VisualizerEditorHeaders.h If the processor is a Visualizer, this header should be used for the editor instead of the generic EditorHeaders.
• VisualizerWindowHeaders.h contains the headers needed by Visualizer windows and graphic canvas.
• SpikeLib.h contains helper methods to allow working with spikes, including functions to pack them into standard data structures as well a specific visualization methods.
• SerialLib.h contains some helper classes and methods to use serial port communications.
• DataThread.h contains all headers needed to crearte create a DataThread class and plugin.
• RecordingLib.h contains all headers needed to create a Record Engine class and plugin.
• FileSourceHeaders.h contains all headers needed to create a FileSource class and plugin.
• PluginInfo.h contains headers related to the plugin information structures and methods. Should only be needed by OpenEphysLib.cpp

There are a number of rules that all plugins must follow:

• A plugin should be as much self-contained as possible.
• A plugin must not need depend on other plugins to work.
• No plugin Plugins must not make use of any GUI Source headers outside of those provided on in Source/Plugins/Headers.
• Plugins must not acquire by any means, nor use, direct pointers to other processors or any other class or code in the GUI outside the scope of the plugin itself.
• As such, any external functionality must be called via the CoreServices namespace. Extra information can be passed down the chain by creating specific event channels, through the ChannelExtraData class.
• No communication Communication between processors or parts of the GUI outside the available methods must be usedis not allowed.

Outside those rules, there is are no further limitations on what the plugin can do. Plugins are free to make use of external libraries and any other means needed to achieve their functionality. Although it is highly recommended that a plugin can be compiled on all three platforms, nothing prevents a library from being specific to a single OS, as long as the build files take that into account.