The development branch of the plugin version of the GUI can be found in its own github repository: https://github.com/open-ephys/plugin-GUI 

Once it's been tested for stability, it will replace the current static version of the software.

Thanks to Yogi Patel for his initial contributions to the plugin architecture.

Downloading binaries

Precompiled binaries are available for the following systems:

• Windows 32bit
• Windows 64bit
• Linux 64bit
• OS X 10.11

Building the plugin-based GUI

Building the core GUI follows the same steps that the non-plugin version, listed on the Installation page for each operating system.

To compile the plugins follow these steps. By default, the build process will copy the plugins into the appropiate plugin folder inside the building path.

On Windows

1. The GUI must be compiled prior to the plugins, as the plugin build process needs the open-ephys.lib file created by doing so in its default directory.
2. Open the VS solution file Builds\Visualstudio2013\Plugins\Plugins.sln
3. Select the appropiate architecture and release mode that matches the one the GUI was built with.
4. Either build the complete solution to generate all plugins or build specific projects to compile just specific ones.

On Linux and Mac

1. Using a console, enter the Builds/Linux or Builds/MacOSX directory
2. Execute the following command: "make -f Makefile.plugins" to build all plugins

• To clean the plugin build space, type "make -f Makefile.plugins clean"
• To compile just a specific plugin, type "make -f Makefile.plugins <NameOfThePluginFolder>"
• Only those plugins that have a Makefile file inside their source directory will be built

Running the plugin-based GUI

Running the plugin-based GUI is no different than running the regular GUI. All the plugins located on the "plugins" folder next to the excutable will be loaded at startup and available as usual.

Note that trying to load a signal chain from the non-plugin GUI into the plugin GUI or viceversa won't work and might result in a crashStarting 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 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 in the signal chain. This kind is the most extensive, as processors can be wither 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 plugins are used by the SourceNode core processor to asynchronously access source data, usually from acquisition hardware, allowing to implement controller nodes for multiple different hardware devices.
• RecordEngine plugins. Record Engines are the classes uses by the record subsystem to store data in disk. They allow to define multiple file formats for recording data.
• FileSource plugins. The inverse of the Record Engines, this plugins are used by the File Reader to load different file formats for data replay.

Overview

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

Library Files

Those 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.

There are two main limitations in the use of external library files:

• 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 the API do not 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 the same compiler must be used for two. Different versions of the same compiler might or might not be compatible between them, which 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 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.

GUI Services

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 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, exported through the GUI itself.

Creating plugins

Creating a plugin is a matter of 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 there. 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 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 as much self-contained as possible.
• A plugin must not need other plugins to work.
• No plugin must make use of any GUI Source headers outside of those provided on 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 creating specific event channels, through the ChannelExtraData class.
• No communication between processors or parts of the GUI outside the available methods must be used.

Outside those rules, there is 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.