An Open Ephys GUI plugin that estimates the amplitude or power of a band-limited
signal: rectification (abs, pow) or rms, followed by optional
smoothing. Place it directly after a Bandpass Filter to get a band-power /
band-amplitude signal.
Acquisition Board -> Bandpass Filter (150-250 Hz) -> Amplitude Estimator (rms) -> Record Node
Note, this is a rectify-and-smooth estimate, not a Hilbert envelope — it is cheaper and lower-latency, but if you need true instantaneous amplitude use Phase Calculator, which computes the analytic signal properly.
| Operation | Pipeline | Sinusoid of amplitude A | Output unit |
|---|---|---|---|
abs |
abs(x) → smooth |
0.637·A | µV |
pow |
x² → smooth |
A²/2 | µV² |
rms (default) |
x² → smooth → √ |
A/√2 | µV |
rms is the default because it stays in the input's units and lands on a
standard scaling. It also always smooths — without the mean, sqrt(x²) is just
abs(x). The scale_to_amplitude parameter applies the per-operation
correction (×π/2, ×2, ×√2) so the output reads as true amplitude; it is
functional but currently has no editor control, so it stays off.
Note that pow output is in µV², but Open Ephys continuous channels have no
unit field — only the channel description records it.
| Window | Behaviour |
|---|---|
Boxcar (default) |
True sliding mean over window_ms. O(1) per sample, exact and interpretable window length. Costs window_ms × fs × 4 bytes per channel. |
Lowpass |
Butterworth low-pass at cutoff_hz, order 2 or 4. O(1) memory, but the "window" is an exponential time constant. |
Boxcar memory at 30 kHz:
| Window | Per channel | 384 ch | 1536 ch |
|---|---|---|---|
| 100 ms | 12 kB | 4.6 MB | 18 MB |
| 1 s | 120 kB | 46 MB | 184 MB |
| 10 s (max) | 1.2 MB | 460 MB | 1.8 GB |
The editor displays the total allocation. For time constants beyond ~1 s,
prefer Lowpass — it is O(1) in memory and is the right tool there.
- in-place (default) — overwrites the selected channels. No new channels.
- append — keeps the originals and appends one derived channel per
selected channel, named
prefix + sourceName + suffix(default suffix_AMP). Derived channels inherit the source channel's type, so the GUI scales and displays them like their input; the trade-off is that downstream plugins see them as ordinary data channels.
Changing the output mode or the channel selection in append mode changes the channel count, so it requires a signal chain update and is disabled during acquisition.
| Name | Scope | Default | Notes |
|---|---|---|---|
channels |
Stream | all | Channels to process |
operation |
Stream | rms |
abs / pow / rms |
output_mode |
Processor | in-place |
in-place / append |
smoothing |
Stream | on | Enables the smoothing stage (forced on for rms) |
window_type |
Stream | Boxcar |
Boxcar / Lowpass |
window_ms |
Stream | 100 | 1–10000 ms, used by Boxcar |
cutoff_hz |
Stream | 10 | 0.1–1000 Hz, used by Lowpass |
filter_order |
Stream | 2 | 2 or 4, used by Lowpass |
scale_to_amplitude |
Stream | off | Apply the amplitude correction factor (no editor control) |
name_prefix / name_suffix |
Processor | "" / _AMP |
Derived channel naming (prefix has no editor control) |
threads |
Processor | 4 | Worker threads |
Download the archive for your platform from the releases page and copy the plugin binary into the Open Ephys plugin directory (API version 10):
| Platform | Binary | Destination |
|---|---|---|
| Windows | AmplitudeEstimator.dll |
%LOCALAPPDATA%\Open Ephys\plugins-api10 |
| Linux | AmplitudeEstimator.so |
~/.config/open-ephys/plugins-api10 |
| macOS | AmplitudeEstimator.bundle |
~/Library/Application Support/open-ephys/plugins-api10 |
The GUI creates these directories on first launch. Restart the GUI afterwards; the plugin appears as Amplitude Estimator under Filters.
Alternatively, drop the binary into the plugins folder next to the GUI
executable — that path is also scanned, and is what cmake --install uses for a
local build.
Requires the Open Ephys GUI checked out as a sibling directory, or GUI_BASE_DIR
set:
code/
├── plugin-GUI/
└── plugins/AmplitudeEstimator/
cmake -G "Unix Makefiles" -B Build -DCMAKE_BUILD_TYPE=Release
cmake --build Build -j$(nproc)
cmake --install Build # copies into plugin-GUI/Build/<config>/pluginscmake --build Build --target AmplitudeEstimator_tests -j$(nproc)
./Build/TestBin/AmplitudeEstimator/AmplitudeEstimator_tests
# or via ctest
ctest --test-dir Build --output-on-failureThe first test build also compiles the GUI's testable library, which takes a few minutes; subsequent builds are fast.
The pointwise operations (abs, square, sqrt, scaling) run along time,
where samples are contiguous, and vectorise — sqrt uses a hand-written
SSE/NEON kernel since JUCE provides no vector sqrt.
The smoothing stages do not vectorise. An IIR is serially dependent along time, and vectorising across channels would need a gather: Open Ephys channels live in separate JUCE render buffers with no exploitable stride, so building one vector costs more than the arithmetic it would accelerate. Parallelism therefore comes from the thread pool distributing whole channels, which is also why the GUI's own Bandpass Filter is structured that way.
Since the pipeline is cheap per sample, it is likely memory-bandwidth bound at high channel counts; more threads will not always help.
See PLAN.md for the full design rationale.
GPL-3.0. See LICENSE.