marmaduke woodman

I've had some trouble constructing OpenMEEG objects directly with the SWIG based API (sometimes segfaults as result), and the examples all seem to use the file-based constructors. Is this normal?

> have a look at: This is what I meant, the objects like HeadModel are constructed by passing the name of a file, where I would have expected a Python...

Also capturing stdout of subprocess is easier than a shared library with stuff like `cout

@Eric89GXL there are several epilepsy s/M/EEG data sets but would require clinical release. Either I could run tests myself or ask the right person about how to pass the data...

If [simulated data](http://nbviewer.jupyter.org/url/docs.thevirtualbrain.org/demos/simulate_surface_seeg_eeg_meg.ipynb) would work, then I'll be able to put it together quickly.

@agramfort wrt binding OpenMEEG I think a Cython module which provides a minimal in-process API would be nicer than the SWIG approach which assumes head model & surfaces are stored...

I'm at a [point](https://github.com/the-virtual-brain/tvb-recon/issues/35) where I need this to work, and I can implement what I mentioned above over the next few weeks, but I think it's worth some discussion...

> we should not rely on brainvisa formats by passing numpy arrays I don't want to replicate that here, it's just what I was doing in the past. Ideally we'd...

I've not done anything here since we're focused on the sEEG currently with lots of subcortical structures, where we don't have source orientation info, so we use a simple 1/r^2...

@mclerc @agramfort friendly question: have there been any updates on MNE-Python OpenMEEG?