Muse headband -- on second look, maybe it's actually pretty good

[Venryx]

Many of you are probably already aware of the product I'm referencing. It's the Muse headband, which has been referenced on these forums already. (would link, but then would need to get permission first, and that takes too long ) However, I think most people aware of it have underestimated its suitability as part of an EILD setup. I thought the same a few hours ago, but then I took another look, and the more I think about it, it actually fulfills most of the things we'd want in a device. 1) Low cost. Starts at $250, and doesn't require any other purchases, as far as I can see. (You can get it for $211 with a referral code.) 2) It's open-backed, and uses dry electrodes, so has lower hassle for use while sleeping. It could probably get a good ways better (eg the Aurora and NeuroOn masks seem better suited for sleeping), but it's at least viable. (compared especially to full-head devices like OpenBCI) 3) Appears to have a relatively high quality sensor system. I say "relatively", because I imagine it's still a far cry from medical-grade devices. But it has five electrodes (5 times as many as most such devices in its price range), and from the couple of reviews I've been able to find, the electrode sensitivity seems good. Here's one such review: Are there any affordable biofeedback devices? - Brain Health - LONGECITY (this is supported by screenshots and a video for a Muse Android app elsewhere, showing graphs of data from the device; they're dynamic, and don't seem like merely noise) 4) It's available commercially, today, for anyone to purchase. No years-long wait times while a Kickstarter campaign's dev-updates inch forward. (not that I hate Kickstarter; I'm a fan, but its projects can get out of hand sometimes) 5) Lastly, and very importantly: there's a rich and easy-to-use SDK for the device! When I saw this part of their website, my interest immediately increased. Again I can't link to it, but if you're a software developer, this is a big deal because it means: * The company's investing more in the long-term. * There will always be a viable way to get the device input, even if they update the firmware or communication pathway. * It's faster to get up and running with software for it. (having a clean API, set-up instructions, and such) * It lets you work on your software for the device "out in the open" without fear of them disapproving at some point of your third-party (ie unauthorized) software. With the above five points in mind, I bit the bullet and have ordered one, despite not having much in way of extra funds. And as a software developer, I've started designing an app for it. Here is the GitHub repository for the project--open-sourced under MIT, and built with React Native (currently bare-bones, of course): https://github.com/Venryx/LucidLink ========== As for the app design: this is where it gets exciting, because there's a lot of different things we can try with raw access to a five-electrode EEG device. For starters, I'm going to try out the small set of apps currently available for the platform. Most interesting is an app for Android that shows realtime data from the headset in a nice graph form, and allows you to output to csv. There's an equivalent one built for desktop too. This step will just be having fun and seeing what's possible with the device in terms of sensitivity, and reflection of my mental state as I feel it internally. Next stage will be starting work on basic functions of a lucid-dreaming headset-linked app, such as some basic data display (ie graph), and starting work on some sort of in-app scripting to process and respond to the data. (I'll probably start by just letting the user type in and store JavaScript code that has access to the data and API, since it already has a JavaScript interpreter for the React Native UI client; there will of course be presets for common tasks like just having an audio file play when REM probability crosses some threshold) Next stage will depend on the earlier ones. But basically, start laying down the future steps toward eventually attempting to reliably detect REM sleep, and cause a range of user-specified actions to occur in response. The most obvious one is playing an audio file. A second could be turning the device's light on (for those that come equipped with a flashlight feature). A third could be connecting to some wireless Android watch with a vibrator or something (I don't have one myself, but I'm pretty sure this is possible). Anyway, it's super exciting for me, because this is the closest I've been to the BCI<>lucid-dreaming combo I've been wanting to experiment with for so long. If there's any software developers here who are interested, a GitHub clone and pull-request are just a few web-requests away. : ) I will update this thread with new posts as I receive the device, try it out, and proceed with app development and experiment set-up.

[Venryx]

Just thought I'd mention that the headset has apparently gone on sale today for $180 at Best Buy (on their site and on Ebay), which is nice. (I missed it by a couple days; though that's fine) Secondly, my muse headband should arrive tomorrow, so then I can begin integration with the app. (and just general testing of the device) Thirdly, the generic portions of the app are progressing well. I currently have the script system working, with customizable hotkeys, and one action available--to play or stop an arbitrary audio file. Once the headset comes, I'll be working on the monitor/visualizer of real-time data page, and then onto integrating the rem-detection system. (the same one used by Jae Choi on the Hackaday project, for the "lucidity research platform" project on github; though I will have to convert it from C to JavaScript (or add bindings/linking of the two)) Anyway, it should be interesting. See you later.

[MilkyDance]

I've googled the device and it looks pretty interesting as far as brain data is concerned. I wonder how easy it is to fall asleep with the band on your head, and if you manage to induce lucid dreams with it. Also I am curious about the quality of data provided by the device, an initial glance at their FAQ doesn't mention the details of brainwaves measured. Older info on Google mentions Emotiv for example providing better data, but that's probably on older models and perheps without the ability to export data. Which Muse model did you get? Thanks for starting this thread, interesting device even outside of lucid dreaming, if your results are good I might consider it as a Christmas present to myself if it's a good Emotiv alternative which can be pricy.

[Venryx]

So it arrived! I've been with it the last few days, and working on my Android app for it for many hours a day. (new technology stack for me, so I'm had some slowdowns from various things) Overall I'm pretty pleased with it. The picking up of thoughts/emotions/moods is less sensitive/useful than I expected, but I found that it picks up eye movements well; well enough that I'm confident it can act as a REM detector. Which was my main intention/use for the product; and it means two way communication is possible, because having the four sensors lets you distinguish between all 4/8 movement directions (up, down, left, right, and the diagonals). I've actually already set up a preliminary "character map" which I'll try selecting letters from with eye movements in the future. As for comfort while falling asleep, I think it can work--though it's not comfortable enough I'd (preliminarily) recommend using it the whole night. Like WBTB, it's best reserved for late morning sleep or naps I suspect; though I'll be trying it both ways to see if it's practical. Software-wise, progress has been good--if a bit slower than I projected. I just got the headband monitor tab working well (so you can see the raw eeg data in realtime), and I already have the script system, audio file entry area, and settings page + persistence. The next step will be adding pattern-entry and pattern-matching systems, so the user can set up the app to listen for whatever eeg signals/data they want, hooked up to whatever mix of actions they want (play sounds, flash screen lights, delay for 20 seconds, do it again unless the user did a certain eye movement trigger, etc.) [This is getting ahead of myself, but: eventually I also want to add an integrated dream journal system, as well as a long-term dream-data tracking page, where you can at-a-glance see months worth of activity and entries by icon and such, with zoom in and statistical analysis--to help, for example, with testing the efficacy of various techniques attempted. But these are stretch goals; they're likely to come someday, but not worth fretting about yet.] So that's exciting. But yeah, right now I'm trying to buckle down and get: 1) pattern entry and matching, and 2) reliable REM detection. Once those two basic (conceptually) things are in place, the core function of the app will be ready, and I can get down to actually testing it! You're all welcome to join me if you'd like, as the software's fully open and on GitHub. Granted, at this point only other programmers--or really dedicated people--could actually make builds of the project and get it on their device, but in the coming weeks I'll try to wrap things up enough to put a public build on Google Play. The initial version will support Android 5.0 and up (with design intended for tablets, but it should at least work--if clumsily--on phones), but I'll consider adding support for 4.4 in the future. (and possibly even iOS, though I do have more hesitance with that since I don't personally use Apple devices) Anyway, time for screenshots. (most of these are from the $10 Muse Monitor app, as it's currently more fully-featured than my own project) Take care to look closely at the patterns if you're wanting to determine the distinguishability of the actions; from what I can tell, each of the actions are distinct enough for a properly programmed app to tell the difference between them 80+% of the time--but time will tell. Channels: 1: back-left (ignore the noise/wiggliness of this; the wiggliness is entirely caused by my fan which I had running on my left the whole session; apparently fans emit a fair deal of electromagnetic effect) 2: front-left 3: front-right 4: back-right Blinking both eyes quickly. Notice that the bottom channel (and top, if it weren't wiggly) are clearly distinguishable between crests. Screenshot_2016-11-24-19-26-24.jpg Looking up and down quickly. This looks a bit messy/confusing at first, but that's because up and down movements, as I've learned the last few days, are weird. They don't just go up or down (like left or right pretty much does), but rather they "bounce" from one polarity to the other: an up-glance drops the 4th channel value, before then spiking it, and vice versa for the down-glance. Also, they're all squished together; my apologies, I took these screenshots quickly and didn't do much quality-assurance. There are clearer single shots at the end. Screenshot_2016-11-24-19-26-42.jpg Looking left and right quickly: Notice that the left and right eye channels are reverse of each other. (though odd that the right's weaker; I think that was just me not having it concacting my skin as well for that sensor at that point) Screenshot_2016-11-24-19-27-17.jpg Moving my eyes around haphazardly, quickly. The clearest defined waves seem to be in the middle two (front two) channels this time. Screenshot_2016-11-24-19-27-37.jpg Clenching my jaw firmly. Top and bottom are much clearer here; makes sense since they contact closer, at the ear. (and... does no one else find it odd that sensors at the ear are picking up eye movements so well? It definitely is, since a channel blanks when I take it off, but odd; I wonder how much of that is unintended other-muscle triggering, however subtle it may seem--and how much that assumed secondary action also takes place during sleep eye-movements) Screenshot_2016-11-24-19-29-20.jpg (more below...)

[Venryx]

Rolling my eyes slowly around the perimeter of my vision. Again, a clearly defined pattern that could act as its own signal. Screenshot_2016-11-24-19-29-58.jpg Doing a cross-eyed movement 3 times. Note that going cross-eyed is the only time that the 2nd and 3rd channels move in the same direction; another unique signal. Screenshot_2016-11-24-19-30-53.jpg Doing 2 up-glances from straight ahead to straight above (or as close as I can get anyway ). Screenshot_2016-11-24-19-31-43.jpg 2 down-glances. (sorry, second one was not very good) Screenshot_2016-11-24-19-32-09.jpg 2 left-glances. (sorry again; I will blame it on a weak left-eye-movement muscle : P) Screenshot_2016-11-24-19-32-23.jpg

[Venryx]

2 right-glances. Okay, this set is better. Attachment 9593 The frequency spectrum from the sensors. I have not examined the frequency-based results enough to know how accurate or useful they are; they definitely fluctuate, which is good (better than no change at all), but I haven't been able to extract meaningful data from them so far. (and haven't tried the stock app for it much yet either) Attachment 9594 Heatmap of the frequencies like in the above. The red on the left was from me trying the various eye movements. Attachment 9595 Same thing, but in bar-chart view. Screenshot_2016-11-24-19-37-29.jpg Similar thing showing frequencies, except now it's showing it as a line-chart spread over time. Screenshot_2016-11-24-19-40-13.jpg

[Venryx]

These screenshots are from my being-built "Lucid Link" Android app. EEG Monitor page, showing live EEG data. (the zooming and crest size need adjustment, I know) Screenshot_2016-11-24-21-01-25.jpg A script file opened for editing. (in the future, I'm hoping to add visual scripting or some kind of simpler interface for basic tasks) Screenshot_2016-11-24-21-02-19.jpg The list of default/starting scripts. Note that you can disable individual scripts, letting you easily toggle on and off different behaviors, e.g. to experiment with different signalling procedures, or two try out scripts from other people without having to remove/manually-comment-out your own. (it also just keeps things more organized) Screenshot_2016-11-24-21-02-25.jpg Settings page, where you can add audio file entries. Screenshot_2016-11-24-21-04-01.jpg Logs page. This shows internal operation data, as well as errors, and any custom messages logged from your scripts. These logs are also saved to file for potential access and analysis later. Screenshot_2016-11-24-21-04-43.jpg Well that's all for now! Let me know if you have any ideas for the project. I'll be working mostly on the core stuff for now, but it's also fun to think ahead a few steps, and see what other people have in mind.

[Venryx]

So I'm working on the pattern entry/matching atm (I have the code editors up right now, actually), but thought I'd give a quick update, as opposed to buffering them up as much. (shorter and smaller updates are probably more beneficial) 1) One nice thing is that, on trying it out some more, the headband is actually pretty comfortable. I think it'd work fine even for the whole night. 2) The main problem is just making sure it doesn't slip off. One way to solve it, is just to have the app wake you up gently if it ever notices that the headband is receiving no signals. That's simple, and should work fine. May take some getting used to--that is, having occasional wake-ups from a bot that's displeased you let your headband slip off--but I think with time, it'll just be automatic and won't disrupt sleep too much. 3) I realized that this setup, apart from detecting REM and waking you up gently to start a DEILD entry, also has the benefit of acting as a scary-dream wake-up system. It's actually pretty simple. Use the system above to ensure the headband data is streaming in throughout the night. Then start listening for a clear, yet also unlikely to be accidental, signal--from what I've seen/tried, the best match seems to be the "Moving eyes around haphazardly, quickly" pattern (seen above). If the person becomes too scared of something, for whatever reason (eg sleep paralysis for the first time--where even then eye movement is still possible, which is nice [see here]), they just perform the eye signal (and the pattern is continuous, so they should be able to do it even if panicked); the app then begins playing an audio file, fading to a very loud volume over 30 seconds or so--loud enough that there's no way you could sleep through it. The person will then wake up. And signal it to turn off. Either by blinking a set number of times (another clear signal), or by just pressing a button on the app or something. Will be fun to try this out sometime in an actual nightmare, as I'm pretty sure it will work and be a nice back-up plan for people who want to "ease in" to more concerning experiences. Anyway, that's all for now: back to coding.

[vmirinav]

Hi, I have just ordered a headband yesterday and it should come in Monday, paid $150 for a new one on Ebay. At this point I have a selection of Hemi-Sync tracks worked out in an order that lets me ether OBE or become Lucid in the dream during the track progression. My success rate is high at this point with average of 3 OBE's per week. My goal at this point is to record an OBE and a Lucid dream with the device and analyze the results. I don't know how I will apply the data after it is gatherer. It would be nice if I could increase my OBE rate from 3 to 6 per week, so doubling it. I hope the device fits me well and I will get used to it fast without disrupting my OBE rate. I hope to add some value to your app development.

[Kaan]

Hi, very interesting, you do a incredible work. As I am back to lucid dreaming I have been experimenting with one of my REM Dreamer again which has rather good rem detection abilities. I was wondering if you were aware of the interesting but not so well known differences between phasic REM and tonic REM. If you aren't I suggest you to read about it, it will probably be useful for what you are doing. According to my understanding, phasic rem is the part of the rem stage that is the most vivid in term of dreams, with obvious rapid eye movements and and it is as hard to wake up a sleeper in phasic rem as it is in nrem stage 4. Those phasic periods are also shorter than tonic rem periods. So phasic rem seams to be the more interesting rem part for lucid dreaming, theoricaly the easiest rem period to detect but also the one with the strongest dream shield so the stimulus have to be pretty strong if you want them to be noticed within the dream and even stronger if you want them to wake you up for a deild purpose.

[Venryx]

Hi, I have just ordered a headband yesterday and it should come in Monday, paid $150 for a new one on Ebay. At this point I have a selection of Hemi-Sync tracks worked out in an order that lets me ether OBE or become Lucid in the dream during the track progression. My success rate is high at this point with average of 3 OBE's per week. My goal at this point is to record an OBE and a Lucid dream with the device and analyze the results. I don't know how I will apply the data after it is gatherer. It would be nice if I could increase my OBE rate from 3 to 6 per week, so doubling it. I hope the device fits me well and I will get used to it fast without disrupting my OBE rate. I hope to add some value to your app development. Great to hear, vmirinav! Getting 3 OBE's is indeed really good. Even published authors on the topic seem to get around that range. Recording the eeg data from OBE's and lucid dreams should be interesting. I'm of the view that OBE's are a form of lucid dream, but if they ended up showing differently eeg-wise, it could be a launch-point for additional research (eg trying to morph an OBE into a lucid dream or vice versa, see what qualitative success results, and then see how much that transition is reflected in the eeg data) Note that the program I'm building doesn't yet let you track eeg data over a long period--it only shows the last 5 seconds or so. There are other apps that I believe can accomplish that, though. Main candidate is the Muse Monitor app for Android. If you don't mind connecting to your pc (over bluetooth I believe), I'm pretty sure you can also use Muse Labs to record long periods of data. You could then open the data in Muse Labs and examine it after you wake up. In any case, I definitely plan to add support for long-term eeg tracking in my app, so if the above solutions don't work, it should come eventually through updates. As for getting used to it while sleeping: I'm interested too! I haven't actually slept with it on yet, as the app's not ready yet, but in a day or three it should be ready, and I can start giving preliminary results. And yes! Definitely feedback on the app will be helpful. It's not currently actually on the Google Play store, though I'll try to get it up within the week. (or at least submit it; I don't remember how long the review process is) I'll post a link here when it's ready. : )

[Venryx]

Hi, very interesting, you do a incredible work. As I am back to lucid dreaming I have been experimenting with one of my REM Dreamer again which has rather good rem detection abilities. I was wondering if you were aware of the interesting but not so well known differences between phasic REM and tonic REM. If you aren't I suggest you to read about it, it will probably be useful for what you are doing. According to my understanding, phasic rem is the part of the rem stage that is the most vivid in term of dreams, with obvious rapid eye movements and and it is as hard to wake up a sleeper in phasic rem as it is in nrem stage 4. Those phasic periods are also shorter than tonic rem periods. So phasic rem seams to be the more interesting rem part for lucid dreaming, theoricaly the easiest rem period to detect but also the one with the strongest dream shield so the stimulus have to be pretty strong if you want them to be noticed within the dream and even stronger if you want them to wake you up for a deild purpose. No, I wasn't aware of the two types of REM. I think I've heard them referenced before, but didn't think of it while developing the app. I'll look into it and see if it provides ideas/direction for updates to the protocol. (e.g. perhaps having different wake-up procedures depending on what type of rem the person seems to be in) Thanks for the mention!

[Raipat]

I have a Muse since summer and love it. It's SDK is nice, EEG data is clean and useful, especially for neurofeedback and to verify what binaural audios do to my head. BUT I can't sleep with that thing on without it bothering me or losing electrode placement. Thanks for opensourcing you code, I will take a look at it

[Venryx]

I'm somewhat mad with myself because I've been slacking off the last couple days. Anyway, the eye tracking (glance left and right) works well now--at least when I'm awake. I haven't tried it at night yet. (but will tonight) I wanted to make a video on it at the same time, but my laziness led to me not yesterday or today. Hopefully tonight or tomorrow. But I figured I'd make this post in case I lazed out again--at least you'll know what I'm up to. Which is, adding a basic dream journal feature to the app tonight. For now it'll just save it to a text file--but will be slightly helpful in that it'll record the current time (or with an offset, eg "1hr ago"), and provide an easy listing of recent entries. Anyway, I'll get to work I guess. I'll upload the app to Google Play within the week hopefully. (depends on how much work the data recording is for the Tracker tab)

[Venryx]

Dream journal complete. Okay, I lied; not complete. But the basic functions are there: seeing entries by month, adding new dream entries, setting date and time (it starts as current time), marking whether it was lucid, entering title and text, and deleting In the future, I'd like it to also have a tagging system and a search feature, if all goes well. (and then later, integration with the eeg tracker, and perhaps a public dream sharing portal--kind of like here on dream-views, except for people too lazy to open a web browser : P)

[Venryx]

My first night was odd. I was able to sleep with it on, but it didn't show sensible results when I got up. I think because it wasn't contacting my head correctly, so was largely noise which kept falsely triggering the eye glance detection. This will be mitigated in the future by having a noise slowly increase if the electrodes aren't contacting the skin properly, until the user fixes the placement. Anyway, today I'm hoping to start on the Tracker tab/panel, which is the last of the initial ones. It'll be helpful for reviewing events, dream entries, and eventually the raw eeg data, that occurred during the night (and any period further back with stored data). This will take a while to get completed, but hopefully the initial version will be done in 3 days or so, and then I can look into preparing to place it on the Play store. (for long-term, incremental updates after that, since there's lots of additional things I want to add--just on a personal-use level, if nothing else) [I'm also delaying the demo video till this is done]

[MasterMind]

I was interested in buying it. But then I saw the reviews... I will wait with my buy until the product and software gets updated. But until then I will follow this thread with great interest. Thanks for sharing

[Venryx]

I was sick for a few days which slowed progress, but here's a quick update anyway. 1) Tracker feature ========== First of all, the Tracker tab/panel is successfully set up to receive and show data in a time-based graph (with customizable display range). Right now it doesn't show much, though... only labels for "events" that are added to the session data through user scripts. 2) Eye-tracking feature ========== I've been experimenting (and researching a bit) to attempt to add an eye-tracker feature to the app. Yep, it's what you imagine! Trying to get it so the directions you look in-dream are captured by the app, and able to be replayed in the morning. I've had mixed, but mostly good, results so far. Not in actual dreams but in a lot of daytime testing, and iterating on the code. Some things I've so far discovered: A: You get much better (~3-4x) sensitivity when the device is resting directly over your eyes instead of your forehead. Some people might be concerned with this, but at least for now I've been using it for testing. I wouldn't sleep on my stomach with it, but it seems like it would be safe enough if on the side or back. Note that it's not pressed into your eyes--it works fine just barely contacting the surface, so I just let gravity hold it there. B: My naive, initial conception of the eye muscles as just "mirroring" each other's movements was incorrect. That is to say, when you look left, and the left-eye's eeg channel change is +10, the right-eye's is NOT -10 as I assumed. Instead, it's something like -8.5. I was confused why at first, but then I looked up illustrations on the eye muscles, which you can see here: Eye Muscle Control That provided a visual base from which I continued testing and conceptualizing. Then I realized that the drop in the right eye's eeg was not in some sort of "opposite movement", but rather from that the outer "Lateral Rectus Muscle" was substantially closer to the device's electrode than the inner "Medial Rectus Muscle", and therefore the drop was just from that outer muscle relaxing--to let the inner one (still on the right side, but toward the nose) meaningfully tense and pull the eye to the left. In other words, the muscles that pull the eye, tense more strongly eeg-wise than the alternate set relax, and that's what causes the eeg to "not balance out". (after all, as mentioned on that site, the eye muscles are always tensed to some degree to keep it steady, and they just fluctuate in strength to yield the movements) C: So what happens when both the left-eye and right-eye eeg channels show an increase in their values? At first I assumed it was when both eyes tensed, which I assumed meant rolling the eyes up to look higher. Well that's true to an extent; if you look far up then far down in your field of vision, you will see this effect--but it's relatively weak, especially for the middle 50% of the vertical visual range. Instead, what I just discovered tonight, is that an increase in both corresponds a good deal more strongly to a "focusing on something farther away", and a decrease as "focusing on something closer" (like when crossing your eyes). Now in my opinion, this is not quite as useful as glance-up and glance-down detection (as that would have meant you could try to outline shapes and have the outline recorded and the like, which would be awesome!). But, we'll take what we can get. And what we get in this case is still pretty cool: Being able to tell how far away the stuff we're looking at is throughout the dream! So imagine flying high above a city, dropping down to a beach, looking around at your group of friends, then looking closely at your hands to bring stabilization and deepening. It's not yet proven doable, but it would certainly be cool to have an app record left-right eye-movements + view-distances from this period, in a playable recording, and a log along the lines of: "view-distance at ~100 meters, view-distance decreases to ~5 meters, eyes look left 20 degrees, eyes look right 40 degrees, view-distance decreases to ~10 centimeters" If it worked, I think this would be really helpful for piecing together dreams in the morning. (I highly doubt it will work as well as the above; although I'm pretty confident from the results I've gotten so far that it will, when mature, have some level of usefulness/practicality in this area of dream-recording.) 3) Other stuff ========== Finally, another thing related to LD for me recently has been trying the DEILD technique(s) detailed by Michael Raduga in his book The Phase. So far, it's been pretty promising. One of the most interesting for me was his statement that whenever we wake up, we basically are still in the phase! Or at least "close enough" to it that we can often get directly back into a dream within seconds. So the idea is that because you're so close anyway, all you need to do is some basic things and a good percentage of the time you'll be able to get back in, despite it feeling like it's all over. (and when it fails, don't spend any more effort, and just go back to bed and remember to do it again next time for another chance) And I've found this to be true. At least it seems so, from the two times I've succeeded in the last few days. The last one, I got back into the dream like 4 times. Of course, I've done this before, but this time I was more confident in it, because of the optimism that "even if you wake up, you still have a good chance to get back in!". I eventually woke or seemed to wake in bed the fifth time, and decided to end because I had a good time and didn't feel like working my way back into the dream again. So I did, and am looking forward to trying it again some more tonight/tomorrow morning. Anyway, it's all very interesting, mixing research/software-development and personal exploration/relaxation (and all the other random stuff mixed in) in this LD arena. Good night from Seattle!

[Venryx]

[Quick update] Basic function of the eye-tracker and new pattern-matching system is in place. The eye-tracker works well enough to be useful, though it's not to the level of a dedicated input device. I might be able to improve this later, but for now it's more of being able to recognize moments in the dream than in being able to track your exact gaze direction. That said, I'll be trying it out in-dream sometime and seeing how it goes. (I'm trying to get the other stuff worked out first) The new pattern-matching system is based on data match-functions, and while it's not as easy for beginners to use (you can't just "store the pattern I just executed"), it's more powerful because: * It lets you add "gaps" with variable length to adjust for variations in pattern execution speed. * It lets you match based on other data like accelerometer values, values in the past, etc. * It lets you run code on "partial matches". E.g. If your pattern has 10 left-right eye movements, you can hook in and receive an event each time one of those movements is executed. (e.g. for volume that increases the more left-right movements you perform in a row, without having to make a new pattern for each one) However, I'm hitting performance issues with sending all the eeg data to the JavaScript side 256 times per second (even with buffering). (sending it to the JS side is what makes it possible to easily implement the above match-functions) So my next task is to look into improving that performance--perhaps by only sending the data from the front two eeg channels, and/or only sending every other packet or something.

[Venryx]

1) Good news. I've improved the performance enough that it runs fine now on my tablet (Samsung Galaxy Tab Pro 8.4). I'll definitely want to speed it up further at some point, so that it can work well not just on higher-end tablets, but also on phones. But for now this is fine, since I'm the only user. : P 2) Another piece of good news: The new pattern-matching system was definitely worth building! It works a lot more reliably than the old one. I'm quite confident it's now able to function as a long-term sleep-exit tool (I've tried it with my eyes closed while awake and it works solidly). For most people this isn't the main focus, of course, but it's nice to know it's there if you ever want to have an external means of exiting dreams. 3) There's only one real risk-point left, and that's whether the device will stay connected and contacting the skin throughout the night. I've only tested it through-the-night once, so I'll have to start doing night evaluations to see if this is a problem. If it is, I'll then look into what could be causing the disconnections and how to solve them. Some possibilities on why it disconnected that one night: * The Muse config is not set to retry enough, so it gave up too early. (I checked the docs and there's a retry-count parameter that I haven't tried yet; it may help the issue) * The app is doing too much work on the main thread, causing the bluetooth communication code to not keep up with the Muse headband's emitted data, and therefore disconnecting. * When it disconnects, I'm not doing the necessary steps to reconnect reliably. (eg calling Disconnect() then Connect() seems to help it reconnect, when doing day tests, and might be worth coding into the app itself) 4) The DEILD approach in Michael Raduga's book seems to be working well for me. I've had 6 lucid dreams in the last 10 days with it, and I haven't even been focusing a lot on it. (basically just applying the knowledge whenever I wake up) Conclusion ========== So yeah, basically I just need to get the disconnect issues settled, then iterate a bit on a rem-sleep detection pattern, and the app will be full enough that I'll want to start using it! The new pattern matching system is already powerful enough to do so, I believe, I just need to do the work of fine-tuning the parameters with real-world feedback till it detect the rem-sleep eye movements, without also having false positives from other events (eg micro-awakenings). Once that's in place, I'll just add a few lines to the in-app script to have it play an audio file, just loud enough to wake me from sleep and make me remember what comes next (the DEILD techniques). Then without moving, I'll try going back to sleep while performing the DEILD techniques, and thus hopefully have a fair chance at lucid dreams each dream cycle. After that, I'll upload a demo video, release the app on Google Play, and begin (less focused) long-term development of additional features--for example, the data recording and playback so you can examine your nightly eye movements and signals each morning.

[Venryx]

So. The results were mixed. I was able to seemingly detect a rem cycle using the device. However I only tried it one full night, because I found it was more annoying than I thought/remembered to have it on while sleeping. The main problem was not the device itself actually, but just that it forced me to sleep on my back. I normally sleep on my side or stomach, so it made me take longer to fall asleep, which I'm not sure I'd be willing to do each night. If I can teach myself to fall asleep quickly and comfortably on my back more often, I'll come back and reevaluate the device more. (I did put an awful lot of work into it, after all!) Also, naps when I'm pretty tired should work fine, so if I get up the motivation one of these days, I'll have some more random stabs at it. (it is pretty fun to get to look over your data from your sleep and try to see what went on) ========== Aside from realizing it affects my sleep more than I thought, the other reason I stopped my tests despite progress is that I had another idea which got me interested, and sort of stole the thunder from my eeg-device explorations. It's one that's been done before to some extent, although I'm trying some modifications to it that I think could help. And that is... you can see the thread for it here : http://www.dreamviews.com/induction-...wakenings.html

[drwho]

Nice piece. Thanks. I was thinking of doing something similar a while back but had the same reservations about keeping the headband in place. Would it not be possible to use a sweat band to keep it secure ? I currently use Thomas Yuschak's latest regime of Galantamine, Alpha GPC, Sulbutamine and L-Theanine to initiate LDs. Seems to work every time, though I leave longish gaps between nights. For those who have not watched the Battlestar Galactica prequel, Caprica, you should take a look at a device central to the story called Holoband. It takes LD to a slightly impossible level but the storyline is good.

[DaneClark]

Any updates to this? I could really use this app if someone has already finished making it. I desperately need to go OBE aa part of a spiritual healing process I'm going through and it seems like it would be the only thing that would work for me

[Venryx]

Hi DaneClark. I'm sorry to hear that you're having trouble entering the OBE state like you're wanting, but I don't think the Muse app would actually be very helpful for it. This is for three reasons: 1) I no longer own a Muse device (sold it on Ebay), so it isn't practical for me to develop it further to refine it. 2) Like I mentioned above, keeping the Muse headband on during sleep is relatively uncomfortable -- enough that I don't think it's a good option long-term. 3) Even if it were comfortable and I still owned the device, I've come to question how useful it is to detect REM sleep. This is because I've been doing more intense experiments where I just have an alarm play every 5 minutes -- yes, throughout the entire night -- and in fact I check the logs and I do indeed wake up every ~5-10 minutes (I keep pressing the snooze button as planned). Despite this intense alarm schedule, it's still not a wonder drug to lucid dreaming/OBE. It definitely does increase the frequency of lucid-dreams, but it's not a guarantee and needs to be accompanied with mental intentions/procedures. I'm currently still following this line (just this morning used it in fact), but haven't yet developed it enough to the point I'm ready to share it with others. I do think it's promising based on results so far, but not ready yet (we'll see how helpful it is in the end), and is definitely not for everyone due to how intense it is. (I've gotten used to it, but many people would not even consider a protocol where you wake up every 5-10 minutes!) That said, I wish you the best of luck with the OBE activities you're attempting. Lucid-dreaming/OBE is indeed a very rewarding/healing process mentally, so I can understand why you're seeking it.

[DaneClark]

Hi DaneClark. I'm sorry to hear that you're having trouble entering the OBE state like you're wanting, but I don't think the Muse app would actually be very helpful for it. This is for three reasons: 1) I no longer own a Muse device (sold it on Ebay), so it isn't practical for me to develop it further to refine it. 2) Like I mentioned above, keeping the Muse headband on during sleep is relatively uncomfortable -- enough that I don't think it's a good option long-term. 3) Even if it were comfortable and I still owned the device, I've come to question how useful it is to detect REM sleep. This is because I've been doing more intense experiments where I just have an alarm play every 5 minutes -- yes, throughout the entire night -- and in fact I check the logs and I do indeed wake up every ~5-10 minutes (I keep pressing the snooze button as planned). Despite this intense alarm schedule, it's still not a wonder drug to lucid dreaming/OBE. It definitely does increase the frequency of lucid-dreams, but it's not a guarantee and needs to be accompanied with mental intentions/procedures. I'm currently still following this line (just this morning used it in fact), but haven't yet developed it enough to the point I'm ready to share it with others. I do think it's promising based on results so far, but not ready yet (we'll see how helpful it is in the end), and is definitely not for everyone due to how intense it is. (I've gotten used to it, but many people would not even consider a protocol where you wake up every 5-10 minutes!) That said, I wish you the best of luck with the OBE activities you're attempting. Lucid-dreaming/OBE is indeed a very rewarding/healing process mentally, so I can understand why you're seeking it. I've discovered that it's comfortable to sleep in it if you use one of those chair/pillow things. I tried to self-hypnotise myself with it while listening to binaural beats last night, and I think I got little tastes of a very precise brain state that might be able to do it. The MUSE could still help me stay in that state for a longer period of time if someone could program an app for that specific purpose.