Re: goutami: Installation steps for pre-3.0.1 Muse SDK


#1

This topic is in response to a question about accessing the pre-3.0.1 SDK instllation instructions that was posted in an unrelated thread. I attempted to move the post normally to its own topic but some vBulletin shenanigans occurred and it was deleted. Sorry about any confusion that may have caused!

You shouldn’t need to use the installation instructions for the old SDK, because we strongly recommend that you use the latest version. It is much, much easier to install and has additional features that you may find very useful. It shouldn’t break anything that you have already built to interface with MuseIO, MusePlayer, or MuseLab. They work almost exactly the same as they did before, but without having to manually install any dependencies.

If you are really determined to use the old SDK, I may be able to restore those instructions temporarily. But we are really encouraging people to use the latest version of the SDK, as I’ve said.


#2

Hi Tom,

I just want to make sure to the steps i have followed for the museSDK2.4.2 ver.
So it means that i can just unintall the old “musesdk-2.4.2-windows-installer” and install “musesdk-3.0.2-windows-installer”.
No need of copying exe file from protoc-2.5.0-win32 into muse folder and the rest of the steps will remain same.
Is that correct!
If so i did it but i am not getting the brain waves like before i was getting in visualizer they are all overlapped when i choose raw-- in Signal Group Options
Thank you


#3

Correct, you should be able to uninstall the old SDK and run the new installer and have things work for you. No need to install Google Protocol Buffers or anything like that.

Can you explain the problem you are having in MuseLab a little more, or possibly post an image? Which OSC path are you attempting to plot and with which type of visualizer (Scrolling Line Graph or Stationary Line Graph)?

The signal groups consist of more than one signal, so you should expect to see multiple traces plotted when you select them. How do they appear overlapped? If you uncheck the “Zero” option in the Signal Group Options menu, the signals will be plotted on top of each other.


#4

Hi Tom,

Yah when i am trying to send at portNo:5000, UDP or TCP and
by loading the configuration which i have download from the Muse site “rawEEG_rawFFT_blinkClenchForehead”

and by choosing the Draw box as " /muse/elements/raw "as mentioined in the Tutorial i am getting the 1st image,

second image when i havn’t choosen any load configuration just choosing the raw signal group option i am getting the overlaped Scrolling line graph like that…

3rd image when i loaded my configuration just by selecting eeg as my signal group option.

in any case the horse shoe is not full, but the data is coreesponding to it is showing good.


#5

Hi Tom,
I am tying to upload the image but it’ is attaching the picture as toosmall


#6

Yeah, for some reason vbulletin seems to do that. Try attaching image as a generic attachment rather than using the image insertion tool.

I’ll look into the vbulletin preferences to see if I can fix this.


#7


image1.jpg


#8

image2.jpeg


#9

image3.jpeg



#10

It looks like you might still be running an older version of MuseIO somehow. The raw_fft data used to be split up into separate messages (see the second image you posted with the many scrolling line graphs), but has been consolidated into four messages, one for each channel, for quite a while now.

When you run MuseIO in the command prompt, what version number does it print out? Did you completely uninstall the old SDK before you installed the new one?

Please go to the command prompt and type

echo %path%

and copy-and-paste the result here.

Following that, try uninstalling the Muse SDK using the uninstaller in the Muse directory, and then run MuseIO again and see what happens.


#11

Hi Tom,

How can goutami be running older version of Muse-IO ang getting those new paths at the left panel ?
I can see there all: /muse/elements/xxxxx (not /muse/dsp/xxxx) and also two of the four /muse/elements/raw_fttx , he has selected raw_ftt0

What else could he get ? The signals are plotted each a bit on top of the next, but there are 129 signals - I believe that’s why he is saying they are overlapped.

Hey goutami, what are you trying to get ?

Please, forgive me for my english too !

By the way, Tom … what’s happening with the new Muse-Player.EXE for Windows ? It crashes when saving .muse files, and locks when replaying .muse files recorded with Muse-Lab.
And also MatLab files (I don’t use them) but since the previous version it only generates small files (2 kbyte to 5 kbytes) no matter how long you record.

Muse-Player was the best tool of the SDK (at least for me), and I have learned a lot of Python from their source codes, even implemented some new functions (like taking all parameter from a text file) and some other new features. Is it possible to release the .py sources together, or made them available to download, since you said in earlier posts that it was open source (I never cared about the install process for Windows).

Thanks a lot,

Eduardo


#12

Hi Tom,

Yes you are right i didn’t uninstall my older version but i installed new one in a different directory and running muse-io.
With the older version i never get to see the raw…
So when i am running muse-io by giving different path i thought it should be ok
as you asked when i typed your code
this is the result
C:\Program Files\Muse>echo %path%
C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\sys tem32;C:\WINDOWS;C:\WINDOWS\Sy
stem32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\ v1.0;C:\Program Files\Google
Google Apps Sync;C:\Program Files\Google\Google Apps Migration;C:\Users\Desktop;C:\Program Files (x86)\Muse;C:\Program Files\Muse

Now i uninstalled older version and tried running muse-io
muse-lab is not getting any streaming…


Thank you.


#13

Hi Eduardo,

I was trying to experiment with new verion SDK .

Thank you.


#14

Ah, good point Eduardo. My mistake. Thanks for notifying us about the bug with MusePlayer on Windows. We’re working on a fix.

The muse-player.py file is no longer included in the SDK, true. It’s just an executable now. However, the output_handler.py and muse_data_handler.py modules are still there if you want to take a look. I’ll look into including muse-player.py in the next release.


[B]goutami[/B], it appears you are plotting the FFT of the signal with a Scrolling Line Graph rather than a Stationary Line Graph. So, actually, what you’re seeing there in the picture with 129 traces is to be expected. That’s just each coefficient of the FFT plotted over time on its own trace. To visualize the FFT in a way that will be easier to understand and look at, you should use a Stationary Line Graph.

The [B]/muse/elements/raw_fftX[/B] paths contain raw FFT data, not raw EEG data. The [B]/muse/eeg [/B]paths contain the raw EEG.

In your first picture, it seems you have selected the raw_fft messages to be plotted on the graph intended for raw EEG, which is not how the configuration file is set up. Is that what MuseLab looks like when you open the configuration file without making any changes of your own?


#15

Yah,
the first image when i loaded the configuration given by Downloaded file and then choosing raw_fft.
I did so because when i load the configuration, i can’t see any streaming messages like this it’s just stopped.
before loading the configuration i was getting streaming messages.
.


#16

Are you absolutely sure that your muse-io command and the port configuration in MuseLab match up? The configuration file on the website is set up to receive TCP, not UDP like in the above image.

Can you copy-and-paste your exact muse-io command here?

It seems like MuseLab is working fine, if you were able to stream messages into it at some point. Port mismatches are a frequent cause of confusion when working with OSC.