MNE MoBI

[Randomidous]

Hey there!

Opening a quick issue on MNE MoBI on @snesmaeili 's suggestion (wasn't sure whether to go for mne-python or mne-denoise).

I need the bemobil pipeline and hate matlab, so I made a decent python implementation which is in beta.
Check source here: https://github.com/BeMoBIL/bemobil-mne
Docs here: https://bemobil.github.io/bemobil-mne/

I saw the suggested structure on Sina's poster and think I could help implement and maintain it. The package I developed is a good starting point. Do consider it is a work in progress that I improve as I go along my analyses and not a finalized package.

Kind regards
Eric

[snesmaeili]

Thanks Eric — this is very relevant, and I think bemobil-mne could be a really useful starting/reference implementation.

The direction I've been thinking about for MNE-MoBI is to avoid reimplementing generic functionality inside one large MoBI package where possible. Instead, I would like to get the generally useful building blocks into the appropriate parts of the MNE ecosystem, and keep the MoBI layer focused on composing them into a reproducible mobile-EEG workflow.

For example, a substantial part of the artifact-removal / denoising side is now being developed in mne-denoise, rather than implementing those methods again inside MNE-MoBI.

For ICA, jamica provides a JAX implementation of AMICA that interoperates with MNE's ICA machinery. We are also discussing exposing the single-model case through MNE-Python while keeping the richer multi-model AMICA API in jamica: mne-python#14207.

One important missing piece for the gait / MoBI side is proper support for trials or epochs with unequal durations. Gait cycles naturally have different lengths, and at the moment a lot of MoBI analysis code has to work around the rectangular Epochs assumption.

We are discussing that here:

• mne-python#14206 — Support variable-duration epochs
• mne-python#14210 — Draft implementation

I already have working gait-cycle and time-normalization code from the MoBI analyses, but I am trying to move the generic parts into MNE in a way that is robust beyond gait rather than upstreaming a MoBI-specific workaround.

So I think your implementation could be especially useful for identifying what should remain MoBI-specific — for example XDF/multimodal synchronization, motion processing, workflow orchestration, gait-specific event handling, etc. — versus what can be generalized and upstreamed into MNE.

Longer term, I could imagine MNE-MoBI being a relatively thin workflow/integration layer built from these reusable components, and potentially being usable alongside or integrated with MNE-BIDS-Pipeline, rather than creating another completely separate processing ecosystem.

So yes, I would definitely be interested in comparing the structure of bemobil-mne with what we currently have and figuring out which pieces can be reused directly, which pieces belong upstream, and what genuinely needs to remain MoBI-specific.