Private codebase; this page shares a general technical summary. Source files, real records and organization-specific information remain private.
Overview
A collection of experimental Python tools for EEG and signal-processing research. Desktop acquisition workflows, offline feature/model experiments and a local audio-upload prototype are separate components. The collection demonstrates research-code organization without publishing participant recordings, model files or claims of clinical accuracy.
Problem and objectives
When acquisition, feature extraction and classifier experiments span different tools, their requirements and limitations can become unclear. Code execution, prediction accuracy and clinical validity are separate questions. Local prototypes accepting uploads also need basic constraints on how filenames and output locations are handled.
My role
Signal processing, feature extraction and development and evaluation of machine-learning prototypes for EEG-based yes/no intent classification.
Solution approach
Desktop acquisition, offline research scripts and the local audio-processing prototype are treated as separate responsibilities. The general workflow explores numerical signal features and classical classifiers. A review-branch change normalizes uploaded filenames and rejects unusable names. Synthetic tests focus on that file-handling behavior; they do not establish scientific validity or successful end-to-end processing of real recordings.
Implementation details
01Experimental work on yes/no communication
I worked on EEG-based yes/no intent classification in research aimed at alternative communication for people living with ALS. My contribution covered signal processing, feature extraction and development and evaluation of machine-learning prototypes. The toolkit represents the software side of these experiments; it does not provide a ready-to-use communication device or a clinically validated system.
02Separating signal streams from offline experiments
The desktop component handles experimental signal streams, while offline scripts focus on numerical features and classifier experiments. Separating these modes makes it possible to examine a feature or model change independently of data acquisition. Live signal quality, hardware connections, participant protocols and model evaluation require separate validation; successful script execution is not evidence of end-to-end accuracy.
03File boundaries in the separate audio prototype
The local audio-upload prototype is separate from the EEG classification workflow. Normalizing filenames and rejecting unusable names limits writes outside the intended destination directory. Two synthetic regression tests address this file-handling behavior. Their count cannot be interpreted as EEG prediction quality, hardware compatibility or a clinical outcome.
Architecture flow
01Handle experimental signal streams in the desktop component
02Explore feature extraction and models in offline scripts
03Keep local audio-upload experiments in a separate web component
04Evaluate each component against its own data and validation boundaries
Conceptual flow derived from project descriptions; not an application screenshot.
Core components
- Experimental desktop signal interface
- Signal-feature and classical-ML research scripts
- Local audio-upload and processing prototype
- Synthetic checks for filename handling
Technical challenges
- Separating hardware requirements from software validation
- Avoiding clinical claims from research predictions
- Confining uploaded-file write locations
Engineering decisions
- Evaluate desktop, offline and web components separately
- Use no participant recordings or real models in regression tests
- Avoid treating a filename fix as complete web security
Testing and validation
- The 7 November 2026 review branch passed 2 synthetic upload tests with audio processing mocked.
- Acquisition, GUI, real audio/EEG, model files and end-to-end prediction were not tested.
Outcomes
- Prepared a filename-handling fix confining uploads to their destination directory.
- Verified rejection of invalid names without starting processing.
Limitations and current status
- No claim of clinical validity or diagnostic use.
- No end-to-end validation with hardware or real recordings.
- Authentication, quotas and concurrent-job isolation require additional design for the local web prototype.
- Only trusted local model files should be loaded.