Porting the OpenBCI GUI to openFrameworks

edited August 2016 in OpenBCI_GUI
There is growing interest recently to port the OpenBCI software GUI to openFrameworks. Grant and Andy, I know you guys were working on this at the first hackathon. Do you think you could link to your code from this thread? Daniel Goodwin, who is working on the BrainWriter project, wants to expand upon your oF code.

I'm also personally interested in seeing this happen ASAP, because oF is my preferred creative coding language.

-Conor

Comments

  • Hey OpenBCI,

    My architectural hypothesis for EEG software is to write it in two modules: a computational modules (in Python) and a graphical interface layer (in OpenFrameworks), with an OSC bridge between the two. I already have a working system of this which I could gladly share, and would also be great to hear you thoughts on this. I could imagine there being some lively debates about this structure, and I'd welcome feedback/perspectives.

    Cheers,
    Dan





  • Hi Dan,

    That's a cool suggestion. Separating computation from GUI is usually a very good idea. Implementing those two functions in different languages (Python on C++/OpenFrameworks) can also be a good idea because you can choose the language that is best suited to the task and you can leverage libraries that might only exist in one of the languages.

    In my opinion, though, it would be best to keep the barrier to entry as low as possible. If we were to use two different languages, it requires a new user to know both languages *and* to set up the toolchain for both languages. These are two sizable hurdles for newbies.

    For my own contributions (I've done the stuff in Processing), I've chosen to stick with one language (Java/Processing) and to stick with the toolchain that is the easiest to setup (Processing).

    That's just my own opinion, though. I definitely like a diversity of opinions...in fact, all this talk of Python and OpenFrameworks is making me think of putting on my big boy pants and finally learning one of these new languages. Gotta keep the mind sharp!

    Chip
  • Why not do everything in Python? As Chip says, learning two languages (especially if one is C based) is twice as hard as learning one. Python is recognised as an easy language for beginners.

    Is there a good reason for using openFrameworks other than you already know it?
  • If it was all backend, I would go with straight python. However, I have yet to see a compelling front-end framework for Python. If you know any, I'm all ears!

    I actually am brand new to OpenFrameworks, and I picked it up specifically for my project with OpenBCI (which will involve an interactive exhibition and generative art). As far as I can see, it's a tie between Processing and OpenFrameworks for best front end tools for those purposes.

    That said, I totally agree that Python is great for early programmers and is great for the computational libraries available by the open source community. I'd like to contribute to the software project in a way that helps as many people as possible.

    Alistair, do you know much about what you want the software to do for your project?





  • Have a look at the gallery here:

    http://kivy.org/#home

    some of the many other python GUI building apps:

    http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
    http://qt-project.org/wiki/PySide
    https://wiki.python.org/moin/TkInter

    As this is open source, build a GUI using whatever tools you like. It doesn't stop anyone else writing a different one. The question is how difficult will it be for someone to build something on top of your work in openFramework compared to Python?

    If you follow the thinking of Eric S. Raymond from ’The Cathedral and the Bazaar’, open source development requires community and splitting community by having two branches wastes intellectual resources.
    I think if you want lots of people to use this hardware, why make it difficult to start? If you consider the path of someone not from a computer science background, there are now many MOOC's that teach python and they will get a return on effort sooner with python than C.
    If the backend to the front end is python they have a chance of finishing a project without stopping to learn other languages and how to get them to interact.

    Again, the beauty of open source is that everyone has the information to build whatever they want, in whatever language they prefer. The danger is that the project will fizzle because the starting communities' effort wasn't focussed and new people were turned off by the barrier to entry.

    I'd also suggest that writing drivers for BCI2000 and OpenViBE should be prioritised and the Pyff, Mushu, Wyrm project is worth supporting too. That would tap into a large chunk of the existing BCI community who would love to have open source hardware.

  • Hi OpenBCI,

    I created a simple open source GUI app in Openframeworks for the MindWave hardware - https://github.com/trentbrooks/BrainWaveOSC/tree/develop. It also outputs the EEG data via OSC, and allows recording/playback of data. While this has been created specifically for the Mindwave hardware- i don't think it would be difficult to port for OpenBCI as it also uses raw serial communication to connect to the hardware via bluetooth.

    Anyway, if you need a hand with any of the OF stuff - let me know.

    Good luck,
    Trent
  • @ TrentBrooks - dude, that's an awesome oF application! Will def check it out more.

    Since the last posting I've been getting stronger with OpenFrameworks, and so I've created ofxOpenBCI: while it's v0.1 software, it should help anybody else building openFrameworks applications

    https://github.com/dgoodwin208/BrainWriter/tree/master/ofxOpenBCI


  • Also, wanted to shout out to Alistair Walsh for his detailed overview of the Python front ends, and to both he and Chip for perspective on the software architecture. Agreed that fewer moving parts (in this case, two different software languages/platforms) is generally better.

    I apologize for not responding sooner, thanks for the great posts.

  • @dgoodwin208 nice work on the OF addon!
  • Interesting, I'd really like to start working with Kivy and OpenBCi. Has anyone successful used the two together? I'd like to be able to view the data on a tablet so I can do alpha training with a patient without having to be sitting at my desk and laptop. Is kivy the way to go? or is there a HTML5/Restful solution out there?
  • @dgoodwin208
    I have a fork of your project and updated ofxOpenBCI there that it works with my 32bit v3 OpenBCI board. I am not sure if it works with 8 bit board too:

  • DavyD,

    Kivy + OpenBCI is something I've been thinking about; the tablet use case certainly has appeal.

    However, Direct OpenBCI to tablet communication (over Bluetooth Low-Energy) is not currently ready-to-go. And even if we had the code for it, BLE has a smaller packet size (20 bytes as compared to 31) and maybe other packets-per-second limits as well, so you'd likely want to keep the USB receiver dongle in any case. Which is probably doable if your tablet has USB host mode.

    So while direct OpenBCI-to-Tablet mode certainly could be fun for while you're wearing your Spiderclaw on your stroll through the park (what if you had to have brainwave-duels to capture Ingress portals?), in a home or clinical setting an OpenBCI - [wireless dongle] -> PC - [wifi] -> tablet data flow sounds like a good option. The tablet having WiFi is a pretty safe bet, and you'd get to use the CPU on the PC for data analysis, freeing the tablet up to just do visualization of the already-processed data.

    If you wanted an HTML5 app, that's also how I'd do it: put a web server on the PC that reads from the dongle, and point the tablet app at that. Trying to write a JavaScript/HTML5 app that parsed raw OpenBCI protocol data directly is not a technique I would recommend.
  • Nice!!! This is exactly what I'm looking to do!!!! How do I present the live OBCI data in html so the web server I install can serve it locally? I'm using a Mac.
  • wjcroftwjcroft Mount Shasta, CA
    The Kivy looks pretty cool.

    As far as JavaScript signal processing, there appears to be a fair amount out there, so that might be divided somewhat between the server and UI.

    https://www.google.com/search?q=javascript+signal+processing

    https://www.google.com/search?q=python+signal+processing

    ---

    My guess is that for BLE, folks will settle on working with fewer channels or less sample depth (16 vs. 24 bits) to keep the link throughput manageable.

  • So when I install the web server, how do I get javascript to read the data coming from the dongle? I was reading about Processing.js and was thinking I could reuse the OBCI processing code but there seems to be a security issue.

    I have data vis code I can use or I may use a framework like kiva but how do I access the live data is my first step. Just want to show a stream of numbers for each sensor in a browser first.
  • edited December 2014
    Hi Again.

    Conner, Murph,
    Are there any tutorials or examples on how to read from the dongle, say in Python?
  • As this thread has drifted significantly from what it says on the Topic, I opened a new one about Python here:

    http://openbci.com/forum/index.php?p=/discussion/226/accessing-openbci-v3-from-python
  • Hi there.

    Has anybody continued down the C++/OpenFrameworks path? I began porting the Gui to C++ this week, starting with the works of Dan and roman3017.

    I have barely started - see https://vimeo.com/150067994 - but I am determined to continue porting until the whole Gui is finished. If you need anything C++ related in the code, now would be a good time to ask for it.

    Has anybody else ported any of the other Gui elements? If so, it would be great for me to hear of it now so I can include that code.

    I personally think that having a C++ and OpenFrameworks solution only is not a bad idea. So far, I only checked the Java version but I will look at the python code before continuing to port for sure.

    I'm new to GitHub so please bear with me. I will release the source code once it's finished.

    I'd be happy about any feedback,
        Holger
Sign In or Register to comment.