A dancer with ALS walked onto the stage. She didn't move her arms. She didn't speak. But the performance happened anyway — controlled by her brainwaves, in real time.
The neuroscience crowd applauded it. The accessibility people cited it. I saw it scroll through my feed, kept going, then stopped. Went back. Read it twice. Left it open in a tab for the rest of the day.
I have something to say about this. And it's probably not what you'd expect from a dev who normally writes about Next.js and Docker.
BCI + ALS + Art: What Actually Happened Technically
What was presented here is a Brain-Computer Interface (BCI) application in a context that almost nobody in the development world is paying attention to: live artistic performance with users who have ALS (Amyotrophic Lateral Sclerosis).
The setup — in broad strokes, because the full paper is still making the rounds — combines three layers:
1. EEG Signal Capture
Non-invasive electrodes on the scalp. This isn't surgical sci-fi. It's standard electroencephalography, the same principle that's existed since the 1920s. What changed is miniaturization and real-time processing.
2. Signal Classification
This is where it gets technically interesting. Brainwave patterns — specifically mu rhythms (8–12 Hz) and beta rhythms (12–30 Hz) associated with motor imagery, the imagination of movement — are classified by models trained specifically for that individual person.
3. Translation to Artistic Output
The classified signal controls parameters: lighting, generative music, visual projections. It's not a binary joystick. It's continuous modulation.
The result: the artist imagines a movement. The room responds.
# This is a simplified version of a typical BCI pipeline for art
# Not the exact project code, but it illustrates the architecture
import numpy as np
from scipy import signal
def extract_frequency_bands(eeg_raw, fs=256):
"""
Extract the frequency bands relevant to motor imagery.
fs = sampling frequency in Hz
"""
# Mu band: movement imagination
mu_low, mu_high = 8, 12
# Beta band: active motor processing
beta_low, beta_high = 12, 30
# Butterworth bandpass filter
b_mu, a_mu = signal.butter(
4,
[mu_low, mu_high],
btype='band',
fs=fs
)
b_beta, a_beta = signal.butter(
4,
[beta_low, beta_high],
btype='band',
fs=fs
)
mu_band = signal.filtfilt(b_mu, a_mu, eeg_raw)
beta_band = signal.filtfilt(b_beta, a_beta, eeg_raw)
return mu_band, beta_band
def calculate_relative_power(band, eeg_total):
"""
Relative power: what percentage of the total signal
corresponds to this band. Key metric for classification.
"""
band_power = np.mean(band ** 2)
total_power = np.mean(eeg_total ** 2)
return band_power / total_power
def map_to_artistic_parameter(mu_power, beta_power):
"""
This is where the dev makes artistic decisions.
There's no single correct way to do this mapping.
"""
# Example: high mu → more light, high beta → faster tempo
light_intensity = np.clip(mu_power * 10, 0, 1)
music_speed = 80 + (beta_power * 1000) # base BPM 80
return {
'light': light_intensity,
'tempo': music_speed
}
This is the heart of it: the technical problem of an artistic BCI isn't that different from any real-time reactive system. Signal comes in, gets processed, something changes in the world. What changes the context is who is on the other side of the sensor.
The Open Source Hardware Devs Are Ignoring
Here's the thing. The open source BCI ecosystem exists, it works, and almost nobody in the web development world is looking at it.
OpenBCI is the name that comes up most. They make the Cyton board (8 channels, ~$500 USD) and the Ganglion (4 channels, ~$200 USD). Both have SDKs in Python and Java, with Bluetooth or WiFi connectivity. There's an ecosystem around OpenBCI GUI that lets you visualize signal in real time without writing a single line of code.
BrainFlow is the library that unifies access to multiple headsets — OpenBCI, Muse, Emotiv, and others — under a common API:
# Connecting to an OpenBCI Cyton headset with BrainFlow
# This IS real code you can run today
from brainflow.board_shim import BoardShim, BrainFlowInputParams, BoardIds
from brainflow.data_filter import DataFilter, FilterTypes
import time
import numpy as np
def connect_and_read_eeg():
params = BrainFlowInputParams()
# Serial port where the board is connected
# On Linux typically /dev/ttyUSB0, on Mac /dev/cu.usbserial-*
params.serial_port = '/dev/ttyUSB0'
# BoardIds.CYTON_BOARD = 0
board = BoardShim(BoardIds.CYTON_BOARD, params)
board.prepare_session()
board.start_stream()
print("Reading EEG... (5 seconds)")
time.sleep(5)
# get_board_data() flushes the buffer and returns a numpy array
data = board.get_board_data()
board.stop_stream()
board.release_session()
# EEG channels are in specific rows depending on the board
eeg_channels = BoardShim.get_eeg_channels(BoardIds.CYTON_BOARD)
eeg_signal = data[eeg_channels, :]
print(f"Captured {eeg_signal.shape[1]} samples from {len(eeg_channels)} channels")
return eeg_signal
# Cyton sampling rate: 250 Hz
# That's 250 samples per second per channel
With this and a ~$200 headset you have real EEG signal. The problem isn't the hardware. The problem is the next step: classification.
Here's the gotcha nobody tells you when you start reading about BCI: models are highly user-dependent. A classifier trained on my EEG won't work on yours. The variability between people — and in the same person from one day to the next — is enormous. That's why artistic BCI projects require calibration sessions before every performance.
The Mistakes You're Going to Make If You Start Down This Road
Mistake 1: Buying the cheapest headset
The Muse (~$300) is popular because it has an SDK and a community around it, but it has 4 electrodes and it's optimized for meditation, not motor imagery. If you want to do anything serious with BCI, the 8-channel Cyton is the reasonable minimum.
Mistake 2: Skipping preprocessing
Ocular artifacts — blinking, eye movement — contaminate EEG signal massively. There's a jaw muscle artifact that destroys frontal channels. Before you classify anything, you need filtering and artifact removal. BrainFlow has some basics. For anything more robust, MNE-Python is the industry standard:
import mne
import numpy as np
def clean_eeg_signal(raw_data, sfreq=250, channel_names=None):
"""
Basic preprocessing pipeline with MNE.
This is the minimum before attempting any classification.
"""
if channel_names is None:
channel_names = [f'EEG{i:03d}' for i in range(raw_data.shape[0])]
# Create MNE Raw object
info = mne.create_info(
ch_names=channel_names,
sfreq=sfreq,
ch_types='eeg'
)
raw = mne.io.RawArray(raw_data, info)
# Bandpass filter: remove DC offset and high-frequency noise
# 1 Hz avoids slow drift, 40 Hz cuts muscle and electrical noise
raw.filter(1., 40., fir_window='hamming')
# Notch filter to remove power line interference
# 50 Hz in Argentina/Europe, 60 Hz in the US
raw.notch_filter(50.)
# ICA to remove ocular artifacts — requires enough data
# Minimum recommended: 20 seconds of clean signal to compute ICA
ica = mne.preprocessing.ICA(n_components=0.95, random_state=42)
ica.fit(raw)
# This requires manual review or automatic algorithms
# to identify which components are artifacts
# ica.apply(raw, exclude=[0, 1]) # example: exclude components 0 and 1
return raw
Mistake 3: Treating this as a generic ML problem
Transfer learning between users is an active area of research. You can't download a model from Hugging Face, fine-tune it with two minutes of your EEG, and expect it to work. The field is called EEG Foundation Models and it's in its infancy. The papers exist but deployable, reliable models don't yet.
Mistake 4: Underestimating the latency problem
For real-time artistic performance, you need sub-300ms latency between intention and output. The pipeline of capture → filtering → classification → output has to be lean. Pure Python with NumPy is viable. Pandas is not. Anything that triggers garbage collection at the wrong moment will break the experience.
FAQ: What People Actually Asked Me When I Shared This
Do you need neuroscience knowledge to get started with BCI?
Not for the hardware and APIs. Yes for understanding what you're actually measuring and not making serious interpretation errors. The minimum useful level is understanding what frequency bands are (delta, theta, alpha, mu, beta, gamma) and what phenomena are associated with each. A week of basic reading and you can work with actual judgment.
How much does it cost to build a functional BCI setup for experimentation?
OpenBCI Ganglion (4 channels): ~$200 USD + electrodes (~$50 USD) + conductive gel (~$20 USD). Total: under $300 USD for real signal. The Muse S is similar in price but less flexible. For a serious artistic project, the 8-channel Cyton (~$500 USD) is the better call.
What's the difference between this artistic use case and the medical BCIs that show up in the news?
Medical BCIs (like Neuralink or BrainGate) are invasive — they require surgical implants and aim to restore motor function or communication. Non-invasive BCIs with surface electrodes are less precise but require no surgery. For art and accessibility in non-medical contexts, non-invasive BCI is the path. The ALS artist in this performance used surface electrodes.
Why aren't web devs paying attention to this?
Because the toolchain doesn't go through npm. It goes through Python, scipy, MNE, physical hardware, and IEEE papers. It's a different stack from what most of us operate in. And the market isn't massive yet. But the Web Bluetooth API exists, the Web Serial API exists, and there are projects connecting BCI headsets directly to the browser. The gap is closing.
How replicable is exactly what this artist did?
The general architecture: highly replicable with open source hardware and time. The specific calibration that worked for her: not directly replicable. Every user needs their own classifier training process. What's replicable is the technical pipeline. What isn't is the personal calibration.
Is there any risk in using these headsets?
Non-invasive EEG headsets are passive — they measure, they don't stimulate. No electrical current enters the body (unlike transcranial stimulation, which is a completely different thing). For healthy users, the risks are basically zero. For users with neurological conditions, always with medical supervision.
Why Devs Should Be Looking at This — and Why We Aren't
I spent the whole day thinking about this. And I think I figured out why it hit differently.
In the last few weeks I wrote about hardcoded keys in AI-generated code, about agents that automate PRs, about whether Git will survive LLMs, about infrastructure migrations. All of that lives in the space of developer experience, productivity, tooling.
This story lives somewhere else. In the space where technology makes something possible that was previously impossible for a specific person. Not "faster" or "more efficient." Literally possible.
An artist who can't move her body. Who can move an entire room.
And the technical stack making it happen isn't a 100M-parameter model running in a Microsoft datacenter. It's Python, scipy, a $500 board, and a model trained on data from a single person.
Here's my honest critique: the web development world — mine, yours if you've read this far — is absurdly concentrated in a tooling ecosystem that basically exists to move JSON from one place to another in increasingly sophisticated ways. And there are entire branches of computing, like this one, with genuinely hard technical problems, direct human impact, and active open source ecosystems, that don't exist in our collective conversation.
I'm not saying drop Next.js. I'm not dropping it either. But when I read about contributing to the Linux kernel or when I think about the problem space that devs with a systems background could attack, I wonder if we're looking too far inward at the ecosystem.
I've been in this industry for over 30 years — started on an Amiga at age 5, went through Linux sysadmin, networking, infrastructure, and landed in full stack development. The problems that have always stuck with me are the ones where the technology stops being about the technology. Where it becomes about what a person can do because of it.
If any of this resonates and you want to experiment: BrainFlow has working Python examples you can run without real hardware, using synthetic data. That's the best entry point. You don't need to buy anything to understand how the pipeline works.
What you will need is time. And the willingness to work in a domain where the feedback loop isn't "I ran npm install and it worked."
But for an artist who walked onto a stage and controlled light and music with her imagination, someone at some point decided it was worth it.
