Date: Thu, 28 Mar 2024 10:34:26 +0000 (UTC)
Message-ID: <132027166.23.1711622066644@fab4c4baa298>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_22_98753324.1711622066644"
------=_Part_22_98753324.1711622066644
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Starting with version 0.4.0 the GUI features a plugin architectu=
re, allowing it to be expanded with external modules without the need to re=
compile the entire program every time a new feature is added. Currently, th=
e GUI supports the following four types of plugins:
- Processor plugins. These plugins are used to create pr=
ocessors that can be placed in the signal chain. This kind is the most exte=
nsive, as processors can be either sources, sinks, filters or utilities. A =
processor plugin can also be a visualizer, like the LfpViewer, and can feat=
ure custom editors and viewport components.
- DataThread plugins. These plugins are used by the=
SourceNode core processor to asynchronously access source data, usually fr=
om acquisition hardware, allowing you to implement controller nodes for mul=
tiple different hardware devices.
- RecordEngine plugins. Record Engines are the classes u=
sed by the record subsystem to store data to disk. They allow you to define=
new file formats for storing recorded data.
- FileSource plugins. The inverse of the Record Engines,=
these plugins are used by the File Reader to load different file formats f=
or data replay.
Overview
The main elements of the plugin architecture are the library files, the =
Plugin Manager and the shared services that the GUI offers.
Library Files
Library files are the compiled binaries that contain the different plugi=
ns. A single library file can contain multiple plugins of different kinds, =
exporting a set of methods that allow the Plugin Man=
ager in the GUI to inspect its contents and know how to instantiate the dif=
ferent 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 operatio=
n, and the number of plugins each library contains if load its succesful.=
p>
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 chec=
ked against the one of the running GUI, and they will not be loaded unless =
the API versions match.
- The library must have been built for the same OS and with the same comp=
iler as the GUI. Since the libraries make use of many C++ classes inside th=
e GUI code and viceversa, both must be binary compatible, which means they =
must have been compiled by the same compiler. Different versions of the sam=
e compiler might or might not be compatible between them, so this should be=
tested on a case-by-case basis.
Plugin Manager
The Plugi=
nManager is the class responsible for loading and managing plugins. It =
maintains a list of all loaded libraries and the plugins they contain, and =
can be accessed via AcessClass to instantiate a specific plugin. It also pr=
ovides search capabilities to be able to load plugins from signal chains ge=
nerated 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 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 a=
re exported through the GUI itself.
Creating plugins
Creating a plugin involves creating the desired plugin classes, exportin=
g the library info methods, and creating the require=
d build files.
On the development branch, a new and easier method has been implemented.=
Developers can just use our plugin template a=
nd follow the simple instructions to create new plugins.
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 in that directory. The available headers are:<=
/p>
- ProcessorHeaders.h contains all headers needed to crea=
te 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 V=
isualizer, this header should be used for the editor instead of the generic=
EditorHeaders.
- VisualizerWindowHeaders.h contains the headers ne=
eded by Visualizer windows and graphic canvas.
- SpikeLib.h contains helper methods to allow worki=
ng with spikes, including functions to pack them into standard data structu=
res as well a specific visualization methods.
- SerialLib.h contains some helper classes and methods t=
o use serial port communications.
- DataThread.h contains all headers needed to create a D=
ataThread class and plugin.
- RecordingLib.h contains all headers needed to cre=
ate a Record Engine class and plugin.
- FileSourceHeaders.h contains all headers needed to cre=
ate a FileSource class and plugin.
- PluginInfo.h contains headers related to the plugin in=
formation 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 self-contained as possible.
- A plugin must not depend on other plugins to work.
- Plugins must not make use of any GUI Source headers outside of those pr=
ovided in Source/Plugins/Headers.
- Plugins must not acquire by any means, nor use, direct pointers to othe=
r 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 spec=
ific event channels, through the ChannelExtraData class.
- Communication between processors or parts of the GUI outside the availa=
ble methods is not allowed.
Outside those rules, there are no further limitations on what the plugin=
can do. Plugins are free to make use of external libraries and any other m=
eans needed to achieve their functionality. Although it is highly recommend=
ed 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 tak=
e that into account.
------=_Part_22_98753324.1711622066644--