Neuromore Studio on Linux?

Tags: #<Tag:0x00007f629011c368> #<Tag:0x00007f629011c098> #<Tag:0x00007f6290143710>


Does anyone (@Manuel_Jerger?) know when Neuromore Studio will be available for Linux? I didn’t see any info about a release date on the Neuromore site.



We don’t have a release planned right now. However, the integration into our build chain shouldn’t take too much time, so chances are high that we will release a Linux build some day.


@Manuel_Jerger The Linux support would be great (e.g. openBCI works great on Linux already with other software and now there is a new version coming with tDCS) and it’s easier to develop on Linux for devices like that. If I understand correctly, the neuromore studio is powered by Neuromore engine which can be run anywhere ( as it says on your site “Cross-platform enabled (Windows/OSX/Linux/iOS/Android/Embedded)” ). Or how the studio and engine relate to one another? Is the studio a GUI for the inherently headless neuromore engine than can run all many devices? If so, is it possible / will be possible to run engine on one device and the studio on another (like designing a session in a GUI and then running that session headless on another device)?

Also, is there some way to connect to an outside world in neuromore in real time (like sending classifier values through a TCP stream) in the community edition? It would be invaluable for hacking and tinkering, because it will enable interaction with other code (simple examples like controlling a robot with your brainwaves or doing something depending on the heart rate).

Otherwise, the only option is to either use other software that can expose signals after processing to the outside world, or to write scripts which process raw EEG, which is a shame considering how awesome neuromore is.

Just FileWriter’s analogue TCPWriter would make a ton of difference, where it just streams values through a TCP stream instead of the disk. Even if it streams them just as CSV it is already going to be invaluable.

Speaking of which, there is a bug in FileWriter that it does not accept UNC path name on Windows.
If you write a path like “.\\.\pipe\testpipe” (which is a valid path for Windows, it’s just a file on a network location) in FileWriter, it will invalidly correct them to “//./pipe/testpipe” and show an error.

In case, this is something unfamiliar, it used a named pipe. E.g., here is an example of appending “hello” to the file on that path (through the command line in Windows):

echo "hello" > \\.\pipe\testpipe

This is an equivalent of FIFO named pipes in Unix, where the app appends to a file normally, but behind the scenes the data does not really go to a file but it transparently streams to a pipe instead.

I haven’t tested whether named FIFO pipes with neuromore on OSX work. They probably should because it does not have butchered paths for them (i.e. they are located among normal files).

In case you’ll ever want to fix or test it for Windows (IIRC, this is just about rejecting a valid path name, as invalid, otherwise the interface is just the same as writing to a normal file, i.e., Win API CreateFile() ) , here is a small c# CLI (source link) for Windows that creates a named pipe for you to test writing to it, if you’ll ever need it. It will simply output the value appended to the FIFO (output once you run it):

    par@par-PC MINGW64 /c/WINDOWS/Microsoft.NET/Framework/v4.0.30319
    $ ./pipeserver.exe
    NamedPipeServerStream object created.
    Waiting for client connection...Client connected.
    Received from server: "hello"

This CLI can be complied without Visual Studio (IIRC, Mono does not support pipes for Windows):

    par@par-PC MINGW64 /c/WINDOWS/Microsoft.NET/Framework/v4.0.30319
    $ ./csc.exe /out:pipeserver.exe pipeserver.cs
    Microsoft (R) Visual C# Compiler version 4.6.1055.0
    for C# 5
    Copyright (C) Microsoft Corporation. All rights reserved.

    This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see

Above the path is the location of the .net framework and csc.exe accepts two arguments /out:[executable-name-that-it-will-output] [filepath-to-the-code-to-compile]

Anyway, what you’re doing is awesome. Keep up the good work!



@cyrbon: I compiled the studio on Linux just a few days ago :slight_smile: its far from finished and I’m not sure how long it will take until we can release it officially, but if we do, I can assure you that it will support the OpenBCI devices.

You’re spot on, “cross-platform enabled” means that we have a engine Core written in C++ that handles the signal processing and can be compiled on practically any platform. It can run headless too, even though we haven’t played around with it much yet. The scenario you described is certainly a realistic use case for our Core, one could even imagine running it on a realtime linux kernel, on top of a cheap ARM platform. The latency should be superb compared to a system based on Windows or OSX.

As for the connectivity: right now OSC via UDP is the only kind of network communication the Studio supports. You can send data into the engine with an OSC Input Node and output it again with an OSC Output Node. However, the input node doesn’t support high sample rates yet, so it cannot be used do send EEG raw streams without loosing packets (output stream should work fine). OSC is mostly intendet to transport signals that change slowly, like parameters or long-term metrics. We’ll optimize this in the future and might even add support for general TCP streams and perhaps LSL.

I’ve never used pipes on windows but seeing now that our file implementation should support it, it might only take a small fix to make it work. Thanks for pointing that out, pipes would be an awesome and simple way to exchange data with the engine.

  • Manuel


@Manuel_Jerger Thanks for the info. Sounds great!

BrainBay with its differently purposed Osci node and TCPSender node corrupted me, so I was expecting to find something named TCPSender or UDPSender/Writer or in outputs :slight_smile: . I now see that the OSC node can be used to stream and that the UDP settings are in Settings. Now it’s obvious.


@Manuel_Jerger what’s the current status of Neuromore on Linux?

Do you know if it runs successfully in Wine, or have you heard of anyone using it this way?