Integrating Muse into an IOS application


I am looking for some general direction on the muse developers SDK.

We’d like to allow users the ability to connect muse with the iphone through our app, and then display EEG data for them using the visualizer, as long as log the EGG data.

I see the SDK data for linking muse with the desktop, but I’m a little confused as to how to go about this on the iOS.



We are still waiting for Muse’s API to be released to be able to use IOS and Android (and even desktops like Windows, MAC-OS and Linux with a real device driver) to connect directly to Muse, collect and process data using bluetooth or serial commands.
We (users and developers) hope that all resources of Muse-IO and more will be available with the API.

By now there are only two options (as explained in other Topics by some Muse team members):

  1. Connet Muse to a desktop using Muse-IO, then use Muse-Lab or Muse-Player (I recommend the latter, wich is lighter and consumes mutch less resources) to get the data and rebroadcast it to the network (your Apple or Android network IP device for example), and then you can use as examples the MuseIOReceivers (for IOS and Android) to process the OSC messages as given in this link:…-started-guide

2, Get to understand the intincated Muse Communication Protocol released at this link:…ation-protocol
and build you own driver to connect directly to Muse from IOS or Android and you be on the way by using your tablet or smartphone developping language.

Needless to say that, as stated at the Developers documentations, in order to save Muse’s battery and perhaps it’s memory and microprocessor resources, the internals of Muse just send raw EEG data and does not deliver any pre-processed data (except a few for battery, and perhaps status if I remember well). That means you’ll have to understand about FFT Fourier Transforms and perhaps some other high math processes, and a bit of neurosciences and BCI’s to get all of those processes that converts data from the time domain to the frequency domain, to be able to get things like the bandpowers of Alpha, Beta, Delta … etc…

HTH, Eduardo.

P.S. It would be nice from the Muse Team, if any of them like Paul, Farough, Matt or even Trevor could comment on technical posts like mine and others, just to endorse, correct or add some usefull info. Not only we can be wrong, but also this approach would tell us that they are following us and they are with us in this hard and complex way. I’m am no allone when we observe that since one post was answered by someone else, they apparentely do not look a it … this approach is not very kind from them :frowning:


It’s a greay idea to allow users the ability to connect muse with the iphone app. I work at an[SIZE=13px] iphone app development company and we also would like to create an app for muse. Contact me if you are interested.[/SIZE]



Great to hear about the details of the Comm Protocol, this enables a new world of apps to be built for this device.

David Vivancos, [+530 Ideas to share] [+647K Brain Signals]
[Type > Touch > Talk > Think]
November 2nd 2014 Idea, “Playfulness drives creativity.”


Hi all, just got my muse and started digging in a bit and I must say I am completely confused about the state of this area.

From most reviews I have read, the main downside of this device was indicated as the lack of functionality for your average user. The obvious answer to that is to give us developers all the tools we need to change that by writing more mobile apps for it. maybe it was a bit naive of me but i actually just assumed that support would be here.

You have a fully functional mobile app already in existence (the app that comes with the muse), why isn’t that open sourced? having that example of how to interface with the device properly would drastically simplify making new apps. i assume it doesn’t work with just any EEG so you have nothing to loose by doing so and much to gain. If I can write a successful new app through that guidance, that just brings you more customers as people would need your headset to use my app and with a few developers doing this, the device all of a sudden escapes from the biggest criticism against it.

Btw, do Muse reps actually get involved in these forums or should i be directing this elsewhere?


Congratulations osusoy!

You was able to in a few paragraphs explain the feelings of most of us developers. For the average user, if they want a bit more than the Calm app, they got a good opportunity by having to learn a bit of the internals of their OS’s

About the Calm app, I don’t believe they will make it open source, as some of the team members have already said here that they can not talk about it. Paul (the developer lead) has even written in a post “it’s our secret sauce” :slight_smile:

What we got until now was a few Python demo apps, some OSC demos for mobile devices (but you have to connect Muse to a desktop using muse-io pseudo-driver and rebroadcast data to the network), now the MCP we are talking above, and we hope the API soon.

And, yes, they come here once in a while. Maybe once a week they roll the dice to see who of them will be in charge.


Hi everybody,

Just want to clarify the current state of the Muse SDK and where it’s headed.

We’re hard at work putting together libraries that developers can use to build apps for Muse. We’ll let you know as soon as we can when they’re available on our developer site. We really want to make it easier for people to build awesome stuff! What we’ve released so far is just the beginning.

That being said, the tools that are currently available allow developers to build pretty much anything for desktop environments. You can even write your own Bluetooth interface to the device, using the Muse communication protocol, which we have described on our developer website:…ation-protocol. Also, as Eduardo mentioned earlier, it is possible to relay the data through a computer to a mobile device using the MuseIOReceiver tools. Developers can use these to prototype apps until a full library is available.


Thanks for joining the conversation Tom,

The problem here is that Muse only offers commercial value for mobile applications so although having some desktop apps (or mobile apps that rely on a desktop) is nice, Muse isn’t useful until I can write proper mobile apps for it. I really hope that all these libraries you are working on are for that purpose. For desktop applications, there are higher resolution portable EEGs for around the same price and we are talking about fairly serious differences in resolution. Muse’s only real advantage is mobility and subtlety; highly valuable for using on the go but the wrong choice for anything else.

There is also that open source issue. If Eduardo is corrrect about your views (it would be great if you could confirm your position on that), it is worrying. You can easily include a license condition that the software can only be used with Muse and any real issues solved. If the software really contains a revolutionary new way of processing EEG data, patent it and include a condition that the technique can only be used to develop other Muse apps. i really can’t see a valid reason for not open sourcing it, doing so doesn’t require you to give up your intellectual property, it can be protected while still sharing the example code with Muse developers. On top of that, if we had access to that sample code, then all of a sudden you are not the only ones working on libraries for developers, we can write our own and share around. A far faster and communal way to progress.

Not doing so, on the other hand, simply sends us the message that if we support your device, we would be competing with you and always be quiet a few steps behind. Once again, the existing app is a good example of this; you can write mobile apps for this device right now but we can’t. Even when you make some tools available for us to work with, we are restricted by what you decide to make available. i could start on an app and midway through it find that you have secretly written something similar but better due to having access to tools better than what you make available to me. I am not suggesting you would act in an unethical manner but half of business is assessing risks and invisible code is a massive risk in software development.

Anyway, I’ll follow future developments and hope they move in a better direction. Muse is a pretty cool device, I would hate to see it smothered to death behind proprietary walls.


Developer Evangelist Tom,

Could someone verify the Mac SDK install instructions?

If you look at the posts that I have made, you will see that I have never been able to get past step 2.4. Unless the SDK install process is creating the /usr/local hierarchy, there is no /usr/local/ on the Mac (at least for the latest versions of OSX) so the library paths are not accurate. Again, details are in my earlier posts.

Fortunately, all that I need for my project right now is “muse-io” and it is working fine. I am on a Macbook Pro running 10.9.5. If I didn’t have a project deadline I would be spending more time trying to figure this out.

Also, the last time I checked, the private messaging did not work which makes communications between forum members awkward.



Hi Tom,

We just released a new version of the SDK (3.0.1) that makes installation way easier. It is just a single standalone installer now, so the old instructions for installing MusePlayer dependencies are no longer relevant. You can download it here:…-site/download

Let me know how it works out for you.

The private messaging issue is known to us. We’ll be migrating the forums over to something more modern and usable in the near future.


I take that as Eduardo’s information being correct. this topic is [B]Integrating Muse into an IOS application[/B] and the only answers are how to install the SDK and forum messaging. well done with going off topic to avoid constructive criticism and feedback from unhappy customers. i can see why the issue comes up in every review of this device though, it took me a single session to master the relaxation app (regular zazen helps)… now what? what do i do next with this $500 device as a consumer (SDK is for devs, not consumers)?


Hi osusoy,

I’m also trying to understand what can be so “secret”, but
the info I got about the Calm app was not my own “conclusion”, they are words written by Tom and Paul, you can see here:…=2015#post2015…-code#post2969

I agree also about the off-topic, but I can understand Tom Karches, he is trying to get the SDK fully installed on his OSX to be able to develop his music projects with Muse, for the last two months or more. I believe he is trying to reach the team members where they appear to be :slight_smile:


Good (or Bad) news: about the API for mobiles and desktops … I’ve read somewhere they are expected to be delivered in the beggining of “NEXT” year !


Thanks Eduardo, the links will help in continuing the discussion. I wasn’t really doubting you either, just wanted a fresh official statement with the hope that the attitude might have changed since you obtained that information.

I should also clarify that my previous post wasn’t intended for TK. I am perfectly fine with him going off topic, we all do that sometimes as conversations progress and seeing how this place is a bit of a ghost town, it makes sense for him to raise his concerns in the most active discussion.

But, that is what forum moderation is for. If this happened on a forum where I am a moderator, I would have moved the question to its own thread (or merge with any existing one) and then answer it there.

What I was really referring to is an official response that not only keeps the conversation off-topic but ignores on-topic concerns too. I guess my delivery could have been better as well but I am raising some very serious concerns about the product and “i only talk to nice people” thing isn’t going to help the product get better. That simply comes across as a case of putting ego before product to me.

On a positive note, this doesn’t seem to be a company wide problem. Their directors are much better at communication and extracting useful feedback from rants (one of the best sources of feedback as it indicates a problem serious enough for someone to get emotional about it). So, I will take this topic elsewhere now but will update this post if anything positive comes out of it. I sort of see this issue (and the off-topic issue of garbage Linux distribution) as a feasibility test. if they insist on taking paths that lead to market failure, it would be silly of me to use their technology as anything I create would be reliant on Muse. If Muse fails, so will my product, simple as that.

Btw, i am disappointed but not surprised about the delays, that is what happens on the proprietary path as there is only a handful of people working on the task (wouldn’t be surprised if it is only 1 or 2 devs)… we could be helping them get it out quicker and a healthy open source community would have developed it for them (and us) already but they have chosen to erect barriers against that so lets tackle those barriers first :confused:


Hi osusoy,

Like I said in my first reply to this thread, we’re building libraries (LibMuse) at this very moment that will allow devs to build native apps on iOS and Android. We can’t give an exact release date - not because we’re being purposefully coy, but just because we literally do not know exactly when it will be finished, and we don’t want to make any false promises - but as I’ve said before in other threads, we’re aiming for early next year, like January or February. That is simply the best estimate we have.

As for open-sourcing the SDK, there is a good chance that it will be. To do so requires not only just releasing the code, but thoroughly documenting it, providing examples, building a proper dev website and forum (as I’ve said elsewhere we are going to be migrating to a different piece of forum software shortly that will hopefully make life better here), and making sure the code is well-architected and easy for developers to work with. That’s a non-trivial task and we’re working on making it happen right now because we really believe it’s important.

The reason I’ve been pointing people towards our existing tools in the meantime is because they make it possible to write software that will work with the full LibMuse-ified SDK once it’s ready for release. The only aspect of your code that this will effect is Bluetooth communication. The OSC receivers can just be replaced with the LibMuse Bluetooth code. It’s totally possible to start developing an iOS app right now using MuseIO and MuseIOReceiverIOS and then later switch to LibMuse.

Eduardo was correct in his post about the two possible methods for developing with Muse right now. The only real difference between those methods and how things will work with LibMuse is the Bluetooth communication, as I mentioned just now.

As for the source of Calm and the Calm algorithm, it’s closed. That’s part of our business strategy, which is not something I can discuss with people outside of the company. Sorry!

We are absolutely working to provide the best tools for Muse devs, and the SDK is undergoing rapid development. The current release gives you access to raw data with which you can build any algorithm you devise, and the included algorithms (which will grow in number) give you outputs you can use out of the box. I think those are both very useful things, and we’re as eager as anyone to get the latest and greatest update into developers’ hands.


Hi Tom,

I have discussed these issues with Paul under Ariel’s gaze and it is now clear to me that your statements are correct, your company will take the protectionist path and Muse will more than likely fail because of that.

I think an office parrot that keeps repeating “be sure to identify what you are selling” is in order. You are claiming to sell a headset with some software included with it. Based on all this new (for me anyway) and verified information, your business strategy revolves around your software instead. So, what you are actually doing is selling software and including a headset with it. Yes, you might at some stage provide some libraries but by having Calm the focus of your business instead of Muse, you are effectively a software company and all external developers are stuck playing the role of competitors. In such a setup, there will always be doubt as to whether the libraries you would make available to us are providing full functionality or are just cut down versions of what you use.

Issues do get really weird when a company sees their customers and supporters as competition so I think the best path for me is to continue my ideas with a different headset.

You are a developer yourself and I’ll assume you have some business sense as well. Would you build software that relies on someone else’s device if the owners of the device treat you like competition and hide all their useful code from you?

Now that I bought it, I might use Muse for frivolous personal stuff but I don’t think anyone with any business sense would get themselves into such a high risk situation as working on a commercial project based on your device while you have these policies and views.



Can only agree with osusoy - what does Muse want to do? Sell $299 headsets or sell apps? Wouldn’t a dozen 3rd party apps HELP in selling headsets? While muse keeps developers from developing apps with a 3 -4 month wait on Libmuse, customers are stuck with the limited functionality of Calm. If the delay is to document, provide examples, etc, why not just open source sooner? Let all of that happen much faster, and for free with the help of more developers.

I am at the point of buying the Melon headset just for their focus tracking app - seems like a ridiculous waste of money - but at this rate I can only hope to see a focus app for Muse in half a year. PLEASE - just save us money and frustration, let developers build apps for you ASAP.