Building an EMG interface requires more than selecting a classifier. Researchers must acquire signals, prepare windows, implement features, connect predictions to an application, and evaluate the resulting control. LibEMG was developed to make those steps available through a shared Python library.
This paper presents the toolkit’s design and demonstrates its use for offline analysis and live interaction. Its contribution is research infrastructure: reusable implementations, accessible examples, and a common path from recordings to an interactive system.
The question
Repeatedly rebuilding acquisition and processing code consumes time and makes studies harder to compare. Small implementation differences can also change results, particularly when signal scales or feature parameters depend on the recording device.
The library addresses that practical problem. It aims to help newcomers assemble a working pipeline while allowing experienced researchers to replace individual components. The question behind the paper is how to support both exploration and reproducible experimentation without hiding the entire control system behind a fixed recognizer.
The study at a glance
- Contribution
- An open-source Python library, documentation, datasets, and worked examples.
- Pipeline
- Data handling, filtering, feature extraction, feature selection, classification, and evaluation.
- Original hardware support
- Myo, Delsys Trigno/Avanti, SIFI Bioarmband, and gForcePro+ interfaces described in the 2023 paper.
- Demonstrations
- Offline analyses plus Snake, Unity, mouse control, Fitts-style evaluation, and mixed-reality interaction.
How we approached it
The architecture separates the stages of EMG processing so they can be used together or individually. A data handler provides access to recordings, while later modules transform signals and fit models. Optional filtering and feature selection are explicit steps rather than assumptions buried inside a demonstration.
The examples progress from conventional feature-based classification to parameter tuning and custom deep-learning models. Online examples then connect predictions to application commands and evaluation tools. This progression exposes the difference between a classifier that scores well on recorded data and a complete system that a person can use.
The design goals—usability, accessibility, reliability, and reproducibility—shape the API and documentation. They are goals supported by the implementation and demonstrations, rather than outcomes of a large comparative user study.
Technical detail: the evaluation
The paper’s custom-classifier example accepts a model through fit, predict, and predict_proba methods. That permits a PyTorch model to share surrounding data handling and post-processing with conventional classifiers.
Its feature-tuning example uses separate validation and testing data. Selecting a threshold on the validation set, then reporting the test result, makes the tuning decision visible. Current APIs may differ from this 2023 description; the maintained documentation is the appropriate source for implementation details.
What we found
The demonstrations show that the same toolkit can support offline comparisons and several kinds of live application. These are working examples of coverage, not evidence that every application has been optimized or that a particular interaction outperforms other input devices.
One instructive result concerns the Willison’s amplitude feature, which counts sufficiently large adjacent-sample changes. In the 3DC example, a selected threshold of 92 gave 89% validation accuracy and 84% test accuracy. The useful threshold depends on signal units and hardware; copying its value without that context would defeat the example’s purpose.
A separate single-participant neural-network example obtained 95% accuracy on a held-out repetition. Rejection and majority voting raised the reported accuracy to 97% while rejecting 14% of inputs. The rejected fraction belongs beside the accuracy because post-processing changes which decisions are retained.
Reading the figures
Read the boxes from data handling through evaluation. The arrows show how earlier outputs feed later stages, while dashed boundaries identify optional processing.
The diagram describes the structure a researcher can assemble. It is not a mandatory sequence for every model: for example, a network operating on raw windows can use the library without a handcrafted-feature stage.
The hardware interface diagram explains a practical part of the toolkit’s design. A device-specific streamer sends channel samples through a UDP port to the data handler. The abstraction separates device collection from downstream processing; it does not mean every device works without a compatible streamer.
What the results do not establish
A common implementation does not automatically make two experiments comparable. Hardware, sampling rates, splits, labels, feature settings, and post-processing still need to be documented.
The paper’s demonstrations are not a longitudinal evaluation of adoption or a controlled comparison of developer productivity. Likewise, original hardware support and defaults describe the publication’s version, not an exhaustive statement about the library today.
Looking back
The paper is most useful as an account of which repeated engineering tasks can be shared without fixing the research question in advance. The feature-threshold example is particularly concrete: a convenient default still needs to be checked against the measurement scale.
A focused evaluation of the toolkit would ask independent researchers to reproduce a specified offline analysis and live interaction, recording implementation discrepancies and completion effort. That would test the usability and reproducibility goals directly.
Read further
Ethan Eddy, Evan Campbell, Angkoon Phinyomark, Scott Bateman, and Erik Scheme. LibEMG: An Open Source Library to Facilitate the Exploration of Myoelectric Control. IEEE Access 11, pp. 87380–87397, August 11, 2023. DOI: 10.1109/ACCESS.2023.3304544.
The design-goals and module sections explain the architecture; Sections IV–V provide offline examples and online demonstrations. Maintained documentation is available at libemg.github.io/libemg/.