Entries tagged 'cat:#100DaysToOffload' (Page 7)

Entry created on 2024-07-05 author:steeph (374) cat:#100DaysToOffload (41) cat:Cars (1) cat:Driving (1) cat:Opinion (9) cat:Stress (1) lang:en (253)

Here's a controversal conviction that I've developed over the past couple of years: Humans are not able to operate a car savely at road speeds. Ergo, humans should not be allowed to drive.

I drive a lot in my current job. I may not be the best of drivers for many reasons but I tend to accept and abide by the rules if in doubt (and in general, because that's what rules are for). I've learned to save gas and breaks by coasting just right. I've learned to adjust my speed not only to road conditions but also to amount and type of traffic. I don't use apps that warn of speed cameras or police check points because I don't have to. I drive sensibly. I'm not payed more if I get to the customer earlier. I gain quality of life if I drive calmly and defensively. By the measurements that I learned in driving school, I'm a relatively good driver. In practice, when I share a road with other drivers, in the real world, I don't think I can count as a good driver though.

Most people seem to make their own rules for the road and assume that everybody will drive by their rules. They drive 5 km/h over, 10 km/h over, 20 km/h over. They assume a right to overtake because they chose to drive 50 km/h over the limit. They expect you to jump a red light if it's been red for less than two seconds. They assume right of way if no sign reminds them of the rules. Not everybody does all of those things. Most people try to respect the rules as they are put down by law (maybe except driving 5 km/h over). But some people, sometimes, follow their own rules, which is when everybody who doesn't gets in their way. That is often argued to be aproblem of "those drivers" being selfish, stupid and/or respectless. But the truth is likely that all of the people who sometimes drive according to their own rules do so because they are convinced that it's the right thing to do. In fact sometimes drivers spend thousands of Euros to argue in court that their own rules where the right ones to follow as opposed to the ones written down in the relevant law. They get angry and frustrated at people who strictly respect the official rules as the other way around. Of course I'm simplifying a lot here to make my point. I'm not describing any particular example for that reason. But I reckon most people don't break rules and make it harder for others on purpose. Two exceptions: Some people sometimes do have the intention to harm others and try to do so by driving a car. And people sometimes spontaniously decicde to provoke other drivers after they felt provoked or feel like somebody should do something about the behaviour of another driver. I can't say anything about the first exception. That's not the topic of this entry. The second exception I'll come back to later when I talk about stress.

So, when driving intend to drive sensibly according to the rules they deem the correct set, and still clash with other drivers, as it constantly happens on busy reads, that means that either simply setting up rules and hoping that everybody will follow them as well as possible isn't enough or that people are always going to make their own rules. I think the latter is close to the trouth considering the amount of work that goes into trying to make people abide by the defined rules (teaching classes, enforcing physically, convincing by extra signs, commercials, punishment, …).

It is so common for drivers to breaks the rules that certain rules are expected to be broken by the vast majority of drivers most of the time. Driving below or at the speed limit is a very easy way to tease other traffic participants. Driving 100 or 80 km/h in the rain where that is required by law is seen as traffic obstruction by most people. Not stopping at a stop sign in a driving test will immediately revoke your chance of getting a licence. But stopping at a stop sign after you got your license tells others that you're a bad driver or an ass. Hardly anybody ever does it. Good driving doesn't only come down to following the rules like I may have made it sound just now. But the fact that despite all the investments some people see the rules as something that should be generally followed and others drive with the assumption that some rules obviously will and should not be followed creates a constant conflict that seems almost impossible to resolve. Maybe truely impossible as long as so many so different infdividuals control cars on the same road.

Another thing, probably the more important one when it comes to explaining why I believe that humans can not drive cars acceptably well, is how hostile male drivers become when driving under stress. And people are stressed. Working full while also having a life is regularly stressful and I don't need to list the range of hundrets of reason why people get overly stressed every day. It's a point that's often made: People chance character when driving a car. They are capable of atrocious thoughts when driving under stress. They are easy to develop hate at other road participants without being able to communicate much with them. It's a known problem. Men build up rage while driving unless they do some really stupid thing. Knowing about your own tendency to react that way to other drivers being on the same road you're going on doesn't prevent you from reacting with anger to repeated small inconsistancies in other drivers behaviours. And with contempt at people who make up their own rules and ignore your rule set. And with hate to manouvers that you see as an indication of a respectless attitude in other drivers. And with rage at the constant occurance of such situations.

Of course rage is not a constant state while driving. And you might say that, all in all, it does seem to work out relatively well because people aren't having accidents every other day. Accidents with injuries are rare with modern cars. But I think that tens of millions of injuries and more than a million deaths per year (WHO report) are about 100 % more than it should be. Above that though, I think that the hostility and trauma that driving under stress generates constantly, whether you are one of the agressive ones or one who swollows without externalising your anger, is enough reason to prohibit humans from driving cars at speeds abover 20 km/h. But of course that is unrealistic. Too late, after humans have been driving cars since they exist.

The common assumption seems to be that this problem will solve itself when selfdriving cars become a common reality and over the then following 20 years most cars will be replaced with ones that don't require a human driver anymore. Only poor people will drive themselves, and later only vintage car enthusiasts. But That's still science fiction. Closer than ever, yes. But not a reality that is here yet, and possibly not even on the horizon.

The solution is simple: Make driving illegal. Force people to find other ways of getting where they need to go. People have to walk more, drive bikes and if they want to ride carriages with horsed more often and for more practical reasons than nowadays. The economy will collapse from the sudden change what's possible at short notice. But the problem that people drive badly will be solved.

SBWG 0.12.8

Entry created on 2024-07-04 author:steeph (374) cat:#100DaysToOffload (41) cat:Bash (31) cat:Code (31) cat:Computer (78) cat:Linux (36) cat:Projects (41) cat:SBWG (18) cat:Scripts (28) cat:Software (53) lang:en (253)

I've recently published a new version of SBWG, my web site generating bash script. The time that I'm able to allocate to working on SBWG fluctuated a lot in the last year and when I do work on it, I often just feel like doing one type of thing. So, when that is starting a new feature, all the other types of tasks can take on a pile that takes months to resolve. But eventually I managed to test and stabilise the features that I've added and changed, edited the README file and tried out the new version with real web sites. Well, testing could be more professionel, but it's okay for a hobby project, I think.

It's been well over a year since I wrote a blog entry about what's new in SBWG. This entry goes through the main new things since version 0.11.1.

A big new thing, at least from the view of the author/me, is that certain options where that makes sense now support multiple arguments. For example if you've edited three entries and want to re-generate just those three, you don't have to run the script three times but rather define the entries like this: sbwg -e ENTRYNAME_1 ENTRYNAME_2 ENTRYNAME_3. The same goes for pages, tagpages, entry attachments and galleries. This doesn't just make it easier and quicker to generate just some changed pieces of content. It also allows the usage of shell globbing (like *, ? and […]) and brace expansion ({…}). For example you can now regenerate all entries that are stored in one subdirectory or all entries whose names start with a vertain string of characters. Another practicle use case is to add external entries and/or to the site that are not stored in the respective directories in the web site's input directory. Using option -E/-P on the contents of an entire directory creates HTML files in the web site's output directory that look like any other of the web site's pages, but without integrating them in the structure of categories and other tags.

There is now a way to create a custom menu in the navigation bar without writing any code in the settings file of a web site. By using the new 'menu:' tag type in the header of a page or entry source file, the page or entry will get added to the menu. This allows for a list of pages you want to link to from the site's navbar, or a nested tree of interesting blog entries. The tag can be used similarly to the 'topic:' tag with the main difference that it doesn't add the entry or page to a list of entries with that topic, but rather directly in the navigation bar. In the default style set that is a drop down menu like the list of categories, authors, languages and topics. But it is just an unordered list, so it can be styled like any web site menu.

The default style set has changed a bit over the year. It basically looks the same but it's a bit cleaner now and is split into more file more logically. It will become even cleaner in the future though. It now also makes use of the new possibility to present the list of categories in the navigation bar in the form of a tag cloud. Audio attachments are better to look at now, especially when there are several audio files attached to an entry. Image attachments are can now be previewed in a modal without loading the (large) original file and without leaving the page. This almost gallery-like display is about as far as I'd like to go without starting to use JavaScript in the default styleset. Some parts of a web site generated with SBWG are now collapsible/expandable. The parts with this new feature are: entry attachments, entire entries on tagpages, entire entries on their own pages, the custom menu, the category list, topic list, language list and author list in the navbar and the entire navbar. By default all of those things are extanded upon page lead and collapsible by clicking/tapping on their titles. But you can add a setting in your settings file for each of those types of things to be collapsed upon page load and expandable by cliking/tapping on them.

Another thing that behaves similarly is content warnings. Hiding the content of an entry, or parts of it, could always be done by hand, e.g. by adding a <details> and <summary> tag pair to the body of the entry. But it is now easily possible by adding a warn: tag to the header of an entry. For example adding warn:This entry contains spoilers. to an entry header results in the entire content being hidden behind a collapsed <details> tag. Initially visible is only the summary "This entry contains spoilers. (click to open)". The default style set makes this warning line very visible but dunking it into a strong red. If the entry has attachments, those will be collapsed and their title marked in red, too. Both the entry content and its attachments will be collapsed by default if the entry has a warn: tag, independently of what your settings for those parts is in the settins file.

New special tagpages: If there are entries that have a language tag and others don't have one, 'nolang.html' will be created that lists all entries that don't have a language tags. Similarly, if at least one entry on the blog has an author tag, but other entries don't, 'noauthor.html' is created and linked to from the navigation bar.

RSS feeds are now created for every tagpage. That means visitors can now subscribe to individual topics or categories or authors or languages. It also means a longer generation time for a complete regeneration process. But permanent caching reduces that to an acceptable amount. Other feed formats are still not created because I reckon that writing those will be particularly fun and satisfying. So I want to get to that when more of the less interesting todo bullet points are done.

Many small changes make web sites with different structures than mine cleaner. Empty directories or menu entries aren't created. There are new hooks for the various different new functions and loops which a user might want to hook into. Various changes around the default language being used for RSS feeds and HTML documents in order to abide by the standards. Many bugs around all sorts of things have been fixed. The logging option works pretty reliable now. It may still be completely removed one day because it's a large chunk in the code, makes the script slower when enabled and can now be entirely replaced by redirecting output from the script on the shell level. The new flags 'hideinfeeds', 'noshow', 'nogal', 'noatts' and 'noheader' control how and where entries are presented and which parts are visible. See the README for descriptions of those flags.

Reading these update blog posts shouldn't be seen as a replacement for reading the CHANGELOG file. If you have a SBWG web site and consider updating SBWG, at least check the CHANGELOG for lines marked with ! since your current version. That makes it much much less likely that you miss something that you should change upon updating SBWG. I mean, I don't think anybody except me uses any version of SBWG. But I've always approached this project working as if it would be used by others in order to produce something that is practically usable without reading and understanding the codebase first.

The list of things that I'd like to do with SBWG is still long and includes heavy changes on how content is placed in the website's input directory. I reckon that it would take me something like 10 - 16 years to get there is I would continue advancing through the todo list at the pace at which I have in the last year. But if I would loose interest at any point along this path, I could feel okay for at least have gotton as far as testing and publishing version 0.12.8 because it's getting closer to looking how I want it to look in regards to the results it produces.

Writing To Think

Entry created on 2024-07-03 author:steeph (374) cat:#100DaysToOffload (41) cat:Blogging (2) cat:Thinking (3) cat:Writing (4) lang:en (253)

Over the last two years or so I slowly realised that blogging is something that I want to do more often. Or writing in general. Often it was when I read other people's personal blogs that that realisation became a little push. One blog post in particular helped me realise what sort of mental processing the activity of writing evokes. Unfortunately I wasn't able to find it to link to it from here. Instead, here is another short blog post on the topic: "The two kinds of writing" by Herman Martinus. The principle that writing forces you to think wasn't an entirely new one to me. I just hadn't ever deemed it relevant to my life before and so never thought about it. Maybe I still haven't properly, because I never forced myself to do so for more than a minute at a time. But I'm writing about it now, so …

In a way, writing forces you to think like explaining something to somebody else forces you to understand what you want to explain first. Sometimes it is in the middle of a conversation that I realise: What I'm saying, or was about to say, is actually not a well thought through concept; but I hadn't realised this before because I never properly thought about it. But the conversation usually flows on. Even if you do take the time to think something through before you continue to talk, somebody else will likey use the pause to interject what they think at that moment. At least most people tend to do that. But when I write, I can pause however long I want, think about what I was about to say, what words are the best ones to describe what I know already but have never expressed, think about the relevance of my next thought and in what context it stands to what I wrote beforeand so on. I can fact-check something, search for a name, title or quote, read what I've written so far and in general take the time that I need overthink my thoughts before they are out there. That doesn't mean that I always do all of this for everything that I write. For example I often don't re-read immedietely after I wrote something, which leads to a lot of typos living permanently in my blog. I don't research what I write about for a post like this. But to put things into words and to structure thoughts itself already benefits my thinking. It takes a long time for me to write. Even a sentence like the last one can have several pauses and a tree of thoughts that may all end up being bretty much irrelevant to finishing the sentence. But I couldn't have known that for sure before thinking them through. I'm a slow writer, which is part of the reason why I don't write as much as I did when I worked less hours. For a long time though I didn't realise that writing it itself can be a recreational activity and that the very reason why I write so slowly is something that can help me in my life. Granted, with a topic like this, I'm not getting much therapeutic value out of it. It's mainly throttling my perfectionist-like attitude on forming sentences that slows me down, as well as dismissing thoughts that I eventually regard as not belonging in the entry. But who knows what some of those thoughts can do in the future. Having had them once may help me make the right connection in a completely different situation some day. But when writing a diary, forcing yourself to think about things can do a lot to set you onto a track to improve your life.

At least 100 new entries will be published here over the next year.

Entry created on 2024-07-02 author:steeph (374) cat:#100DaysToOffload (41) cat:Blogging (2) cat:Writing (4) lang:en (253)

I'll write more regularly here from now on. I won't have more to say than in the past. My thoughts put into words won't be more interesting or important than before. Nor will I have more time or deem writing blog entries more important. The only thing that has changed is that I have decided to write a new entry more often for a year, starting now. After the year: Who knows!

The idea that I'm following with this is that of #100DaysToOffload, a project - apparently started by Kev Quirk - that encourages to make exactly the decision that I just made. I feel that it is just the right form and amount of goal-setting that I need right now. It is voluntary: I'm not forced to do it by anything other than my will to do so. It's free: Nobody tells me what to write, or how long posts must be, or about what. It's forgiving: I don't need to have a 365 or 100 day streak or stick to a strict plan or routine throughout the year. But it's challenging nonetheless: If I would like to be able to sincerely feel that I have accomplished this goal, I need to do something about it multiple times a week. I need to take it seriously and not put it off for a week or two. The routine and fixed plan that I'm glad is not predefined by the challange will have to emerge sooner or later if I don't want this to turn into a new source of constant stress in my life.

I found this idea (and indeed the necessary nudge to write this here entry), from JCProbably's note from yesterday, which kicked off their #100DaysToOffload. This is how I found that note coincidentally: I subscribe to the blog of Herman Martinus. He wrote and runs the blogging platform Bear, which is, judging from the output it produces, a really neat, clean, lightweight, no-nonsense, cool weblogging tool, in case you've never checked it out. Sometimes when I read a post of his I take the time to see what else has been written on his platform recently. Just to give myself the chance to discover something new sometimes. And there on the discovery feed of Bear was the title I’ve been living inside my head too much, which got slightly tangled in some of my neurons when I read it. That feeling always makes me interested enough to click something. And in the case of a Bear blog entry, it's always a safe click without either bate or hate. It's generally a very friendly platform.

I don't know yet what I will write about in the coming year. The character of the blog will not change because I write more. Or maybe it will, if you consider the fact that absence of character is what my blog so far amounts to. Then more regular writing may allow the blog to develop its character in the first place. Anyway; There will be shitposts, incomplete posts, lots of typos, short thoughts and unfinished

Was ich mir in einer Smartphone-App für Klarträumer wünschen würde

Entry Permalink author:steeph (374) cat:#100DaysToOffload (41) cat:Dreams (4) cat:Lucid Dreaming (12) lang:de (41)

Angeregt von einem Post im Klartraumforum, der nach Ideen für und Erfahrungen mit Klartraum-Apps für Smartphones fragt habe ich mal meine Ideen für eine Klartraum-App aufgeschreiben. Jedenfalls die Grundideen. Weil es ein langer Text geworden ist schieb' ich den mal auch hier hin.

Mein persönliches Wunsch-Feature-Set wäre:

Rhythm Napping Player
RC-Reminder
Zentrale Schnittstelle für REM-Erkennung und Aktion

Funktionen, die mich nicht ansprechen, meiner Meinung nach aber gut in eine solche App passen:

Tipps-Feeder für Afänger
Traumtagebuch

Mit Rhythm Napping habe ich persönlich sehr gute Erfolge. Die Funktion wäre relativ simpel: Man wählt ein Audio-Sample aus. Es ist fast egal was. Ein plötzlicher Anfang, wie bei einem Gong, scheint gut zu funktionieren. Es könnten ein paar Sounds dabei sein. Ich würde aber auch meine eigene Datei auswählen können wollen. Die Verzögerung (Einschlafzeit/Zeit bis erwarteten REM) wird in Minuten eingestellt. Der Abstand der Sounds wird in Minuten eingestellt, mit der Option auf "überrasche mich". Dazu sollte auch noch eine Abweichung vom eingestellten Abstand in Minuten eingestellt werden können, vielleicht auch wieder mit einer Überrasch-Option. Damit weicht das Modell von dem des Namensgebers ab. Mir gefällt es so besser. Aber auch eine klassische Folge wäre mir Recht.

Apps, die einen an irgendetwas erinnern sollen, gibt es zwar viele. Aber die Bedürfnisse von Klarträumern scheinen speziell genug zu sein, dass es dafür eine App braucht, die flexibel genug ist, um auf das individuelle Training angepasst werden zu können. Was mir wichtig wäre, sind Erinnerungen in semi-zufälligen Abständen (keine Häufung, Mindestabstand) mit einstellbarer Anzahl pro Tag und nicht schnell Ruhe gibt, bevor der App gemeldet wurde, ob der RC positiv oder negativ ausfiel (ein Slider mit Zischenwerten wäre nett). Ich habe einige Ideen, wie ein RC-Reminder aufwendiger und vielseitiger designt werden könnte. Aber der Nutzen zusätzlicher Verkomplizierungen ist fragwürdig und müsste untersucht werden. Meine Ideen gehen auch in die Richtung Gedächnistraining.

Was wirklich fehlt under den Klartraum-Apps ist eine Möglichkeit, zusätzliche Hardware zur REM-Schlaf-Erkennung und zur Abgabe von Signalen zu verwenden. Selbst wenn man ein Bluetooth-EEG und eine über Bluetooth schaltbare Lampe hat, ist es nicht einfach möglich, letztere zu aktivieren, wenn die Daten ersteres auf REM-Schlaf hindeuten. Was ich mir wünsche ist eine Zentrale, die aus unterschiedlichen Daten versucht, REM-Schlaf zu erkennen und dann beliebige Aktoren schalten kann. Ich sehe nicht, dass eine für diesen Zweck entwickelte, offene Schnittstelle viel Verwendung fände. Eher stelle ich mir vor, vorhandene USB-, Netzwerk- und Bluetooth-Geräte für Klarträumer verwendbar zu machen, indem aus den zur Verfügung stehenden Rohdaten so gut wie möglich erraten wird, wann REM-Schlaf eingetreten ist und dann nach vorher eingestellten Regeln zum Beispiel eine Lampe blinken lässt oder eine Audio-Datei abspielt. Es gibt da diese Java-App dieses Amis, die wohl nur für Windows entwickelt wird, aber über die Jahre eine ansehnliche Sammlung von Plug-Ins für die unterschiedlichsten Datenquellen und Aktuatoren bekommen hat. Ob NeuroSky, OpenEEG, Open BCI, ein eigenes Design, irgendein Kopfband eines dieser Kickstarter, ein rein analoges EEG mit Frequency-Shift am Mikrofoneingang, ein Gamer-EEG-Headset, Philips Hue, Neopixel/WS2812B an einem Arduino, ein paar LEDs in einer Schlafmaske mit einem ESP als USB-Interface, die eingebauten Lautsprecher/ein Bluetooth-Headset, der Vibrations-Motor in einer Smart-Watch, … die eigentliche REM-Erkennung muss aktuell jeder selbst schreiben und fine-tunen. Fast niemand macht das und deshalb sind funktionierende Klartraum-Headsets so selten. Viele dieser Schnittstellen ließen sich relativ bis sehr leicht implementieren. Aber alle auf einmal - die Vielfalt - das ist eben ein Projekt, das leicht abschreckt. Eine infividuelle Lösung mit propritärer Hard- und Software-Kombination erscheint da offenbar attraktiver als eine offene Schnittstelle für Bastler. Eine offene Schnittstelle würde unter dem Strich aber mehr Träumern ermöglichen, REM-Erkennung praktisch zu benutzen. (Ich persönlich finde das ein interessantes Thema und könnte immer sehr viel dazu schreiben. Notwendig ist der ganze Aufwand nicht. Wenn man erst mal seinen Schlaf ein bisschen analysiert hat oder für eine Weile rum-experimentiert hat, kann man auch einfach mit einer zeitlichen Verzögerung ab dem Hinlegen arbeiten und oft genug einen geeigneten Moment für das Signal oder die Stimulation erwischen.)

Es gibt sehr unterschiedliche Klartraum-Kurse und Leitfäden. Die genaue Ausgestaltung ist ja eigentlich nur Geschmackssache, solange man sich mit den eigenen Träumen und Traum-Zielen intensiv beschäftigt und die richtigen Grundlagen vermittelt bekommt. Auch ich habe Ideen, wie ein Anfänger-Training gestaltet werden könnte. Das ließe sich in eine solche App gut integrieren. Einfache Übungsaufgaben, kurze Texte, Gedächtnisübungen, Tipps und Fragen nach dem persönlichen Erleben könnten gut mit RC-Erinnerungen kombiniert und in Alltagstätigkeiten integriert werden. Beispiele für tägliche Aufgaben: "Mache heute jedes Mal einen RC, wenn du durch eine Tür gehst." Zwischendurch Erinnerungen. Am Ende des Tages eine Abfrage, wie gut das geklappt hat. Falls nicht so gut wird die Aufgabe schon bald wieder als tägliche Aufgabe kommen. Auch etwas wie "Trinke diese Woche keinen Alkohol" könnte als Aufgabe kommen. Wenn man eh keinen Alkohol trinkt, gibt man das an und bekommt sofort die nächste Aufgabe. Mir würden so viele kleine und länger andaurnde Aufgaben einfallen, die zu einem individuellen Training zusammengesetzt und je nach Bedarf in ihrer Häufigkeit angepasst werden könnten. Den Zusammenhang vieler Aufgaben hier aufzuschreiben wäre jetzt etwas viel. Ich hoffe die grundlegende Idee habe ich schon rüberbringen können. Die meisten Meldungen wären einfach nur kurze Tipps zu RCs, Denkanstöße, Vorschläge fürs Traumaufschreiben, wie Übungen besser gelingen, Motivation, kreative RC-Anstöße.

Die Traum-Aufzeichnung braucht die App meinetwegen nicht übernehmen. Die Wünsche und Möglichkeiten in Funktionsumfang und Umsetzung sind riesig und es gibt schon genug Apps, in denen strukturiert oder frei Datensätze eingegeben und archiviert werden können. Es gibt auch schon dutzende Apps, die speziell zum Aufschreiben und Auswerten von Träumen gedacht sind. Die Unterschiede sind gewaltig. Natürlich gibt es auch Gründe, weitere solche Apps zu bauen. Jeder hat halt eigene Vorstellungen, wie eine Traum-Aufzeichnungs-App aussehen sollte. Für mich reicht ein einfacher Audiorekorder oder eine einfache Notiz-App. Eine Auswertung der Inhalte in einer Form, aus der ich einen Nutzen ziehen könnte, habe ich noch nicht gesehen und ich bin mir auch nicht sicher, wie die aussehen müsste.

Da das sehr unterschiedliche Features sind, die auch unabhängig voneinander funktionieren, könnte sie in fünf einzelne Apps aufgeteilt werden, die aber zusammen arbeiten und ein gemeinsames Interface haben. Zusammenarbeiten würden die Apps zum Beispiel, indem nach dem Start einer Rhythm-Napping-Session keine Aufgaben oder regulären RC-Erinnerungen mehr kommen. Die Schlafphasen-Erkennung kann auch als Wecker z.B. für WBTB fungieren und zum Aufwecken direkt Fragen zum Inhalt des Traums stellen. (Im Schlaflabor-Studien führt das zu besserer Traum-Erinnerung.) Die Länge und Anzahl aufgezeichneter Träume, die Antworten auf Tagesaufgaben und -Abfragen die Zuverlässigkeit der Reaktion auf RC-Erinnerungen können verwendet werden, um das individuelle Training (zukünftige Aufgaben und Fragen) zu beeinflussen. Die Schlafaufzeichnung/REM-Erkennung kann automatisch starten, wenn eine RN-Session gestartet wird. RN und Versuche, Singale in einen Traum zu senden, könnten automatisch in dazugehörenden Traumaufzeichnungen eingetragen werden. Und so weiter.