Eight device tree talks this week and know all about it and don't need to hear any introductory material. Is there anyone who doesn't know anything about device tree and needs an explanation from A or, okay, and so this is a pretty small audience and there's no point in my just yacking on and on if people don't know what I'm talking about. So I don't see any reason for people not to interrupt with questions. Obviously I'll cut them short if they're going on for too long. Particularly if I'm using acronyms that people are not familiar with, which I have a tendency to do. So there has been a lot of discussion about the device tree. There was a session at the Kernel Summit, which I didn't attend, but which we heard a little summary of from Mark Rutland. In his device tree, The Disaster So Far presentation yesterday, which I greatly enjoyed. I'm going to take a little bit more optimistic approach and try to talk about the bright future of the device tree. There's also an excellent introduction, I guess maybe in the same room by Thomas Pedazzoni and will largely not repeat what Thomas said unless someone really is puzzled by what I'm saying. So I'm coming to device tree from the world of automotive. In the world of a lot of consumer electronics, devices are kept by the user for a year or two years maybe and traded in. And carriers are not always providing kernel updates, even if they're available. And phones and tablets now are almost considered consumables by the people that purchase them. A car is not in that situation. A car is a major purchase by somebody. People expect parts to be available for 10 or 15 years. And I think they will be expecting security patches even though they won't call them that, probably for that amount of time as well. And the whole concept of updating software and cars as part of regular automotive maintenance is new to the auto industry. And the software production and maintenance model for automotive and other products that are going to be installed for a long time, like maybe security systems or ATMs. All the different traditional uses of embedded is quite a different model than the tablets and phones that have dominated the thoughts of a lot of people and embedded the last few years. So this is just the beginning of some ideas about how if we have a product we expect to be in the field for 15 years, we might approach the problem of updates and maintenance when we introduce the device tree into the picture. So, updates of fielded devices are already pretty hard. I don't think I have to tell anybody and embedded that. I think device tree makes it, maybe from some point of view, optimistically a little bit better and maybe from another point of view, harder. Maybe we can make our life a little bit easier by thinking in advance of what are good practices to make the update task tractable. I'm going to talk a little bit about tools that are imminent and tools that are wanted and a little script I made to try to help and I'll try to summarize best practices. So this block thing in the upper left-hand corner is some text that KDE and Debian have decided put on my screen that I can't make go away. So just ignore that. The rest of this is a diagram that's no particular rocket science. It's just kind of a state machine for deciding if an update you're trying to push is complete and coherent and makes sense. There's nothing particularly brilliant or novel about this. The point is just that the state machine involved in updating a root file system or the kernel or both in a field of device and making sure that they have a correct checksum and perhaps they're signed properly is already kind of complicated and painful and now potentially with the device tree we're adding another file that has to be kept in sync with the kernel or maybe we can update the kernel without the device tree. That's something that's been discussed a lot this week already. And so as I mentioned I'm thinking about this from the point of view of automotive and providing long term maintenance and support to customers as part of building a kernel and a root file system for them. And so I do believe that cars will be getting security patches and that they may require new device trees. A lot of people are pushing the idea of device trees as a binary interface between the, it's a contract with user space as with the kernel. The binary interface of the device tree and so maybe we won't have to update the device tree when we update the kernel with security patches. But this black thing is really annoying. But point is is that cars I think will probably want them. And I think that's just practical. I'm not going on a big campaign that we should all look forward to changing out our device trees. But if you're in charge of actually making things work with real products in the field, you find that you do a lot of things that people don't necessarily recommend. So one aspect of cars is they have many processors in them. Just an example that occurs to me where I think people will probably end up updating the device tree as well as the kernel is. If you look at the battery pack in an electric vehicle, it's extremely complicated charging circuit. The batteries are a very complex system with many microprocessors involved in just measuring the state of the battery, cooling them. And so the battery warranty for a brand new Prius in the United States this year is five years. And that battery will certainly be replaced at the end of five years. And I think the technology and the new battery will be quite different. So this is an example of a case where software is going to need, perhaps, to be upgraded. Another point with cars, even from the point of view of the so-called infotainment unit console in the software on that, is that that will control the climate system. And the climate system in an EV runs directly off the battery. I mean, you're not getting heat from the manifold the way you wouldn't in an internally combusted car. So all the driver comfort features are taking the same power that's used around the engine. So besides even security updates, I think we're going to get power updates. And the features of the kernels that go in as far as power and security are always changing. So device trees are supposed to be a hardware description. I think the hardware in cars in the field is actually going to change because of these different dynamics. I think even if people can update the kernel without updating the device tree, their desire to get power and security features will maybe cause them to change the hardware description, even if the ABI is stable. And then another point is, to be perfectly honest, if you look at the device trees we have now, there's a lot of configuration information in them already that is not really a hardware description. I mean, something that I've used, for example, is MTD partition tables. No one can tell me that a partition table is a description of hardware. I mean, a partition table is kind of sort of a description of a real entity on the storage device, but it's not like it's the address of USB or something like that, and you can change it. We have pinmux, resource, and clock stuff in the device tree that we might change. We're selecting boot devices. A lot of this is configuration rather than hardware description. So anyhow, I think we are going to change the device trees. And actually, this is kind of hard. And why is it hard? Well, one aspect that I referred to a little bit before is that cars have a lot of processors in them. They are really rolling data centers. If you haven't kept current with this technology, it's really kind of daunting how complicated it is. The new Mercedes S-Class, according to Mercedes, is going to have 200 microprocessors in it this year. That's astonishing to me. Now, a lot of these are 16-bit microcontrollers that just run a PID loop on the brakes or something like that. And they're not having Linux on them, and they're not going to anytime soon. So they're kind of out of scope for this discussion. But I know for a fact that a lot of the cars, actually, Mercedes is QNX, not Linux historically. But I know that a lot of cars are going to ship with more than one processor of running Linux in them. I wouldn't be surprised if there are cars coming out in 2014 model year that have half a dozen Linux running processors in them. And it may be that only one of them is going to be connected to the internet. So maybe if you're getting that new battery pack, it's getting boards with it, and those boards will have new software on it. But some of these other processors that are part of this data center, this rolling LAN, may need to be updated over the LAN locally by software that's loaded onto the one processor that's accessible from a USB drive or from the internet. So this procedure is really kind of, it's really kind of configuration management of this whole system. I mean, it's almost like enterprise computing in some sense, rather than traditional embedded. Another part about the device tree update that I think a lot of people are aware of, but that people who haven't made heavy use of the device tree won't have thought about a lot, is that the device tree and the kernel configuration have to be kept in sync. And this is kind of obvious, but if you enable a feature in the device tree and you don't build the driver, then the device is obviously not going to work. But this actually can be a little bit tricky. I've worked on something where a multiplexer or a pinmux or clock configuration needs to be changed to enable a particular device in the device tree. And so then in order to use that device, you not only have to build the drivers for that device, you have to build the drivers for the bus it's on. So and if you do update the kernel and the device tree, the names of some of the parameters may change from kernel to kernel. So it's going to be important, certainly, in the future, as a bare minimum to preserve the information about the configuration and the device tree together that you have. And if you have a compilation of the device tree that relies on a whole bunch of include files, you'll have to save all the include files and all the device tree files and the kernel configuration all as kind of sets. And if you have a whole bunch of different products, you're going to have to be very careful that that information is really, really well organized. Speaking for a personal experience, which doesn't involve anything like 10 or 15 years, you have to keep pretty good records of this stuff. So this is just a, people say to show pictures in your talk. So I thought the pictures you'd like to see were screenshots of LKML. But this is just an interesting post from somebody named Jason Gunthorpe, who says that he has basically a script that checks the K config against the device tree. And so that sounds like a good idea. And I guess he hasn't published that script, but that's the kind of example. I'm going to talk a little bit more about tools in a little bit, but that's an example of a kind of tool that would really be useful for the community, although it would require a lot of maintenance. So this says unintentionally under this obscuring black banner. Oh well. Another point about the device tree that was not obvious to me at first is the ease with which one may unintentionally break something that was working. So here, this is just an example that Koon Kui posted to, I guess, the arm mailing list. So it's pretty obvious if you go into the node that corresponds to a particular device and you change the parameters, you're changing the behavior of that driver. I don't think anybody's unclear on that. But what's less obvious is your driver is using resources like the pinmux, its regular voltage, or its clock. And if you make some apparently innocent patch to the device tree to enable another device that's using the same resources, you can break your device without thinking that you're changing it. And this is a little bit of an alarming example that Koon posted where basically he pointed out that he had an unsupported device that no one was using. And when he added support for another device, it could basically blow the one device, the other device up, which sounds pretty alarming.  And you're going to give your user a new device tree to turn on some feature that you do support and you're actually going to alarm them by having smoke come out of this other chip. I mean, that actually honestly could happen. I mean, I had another example where I changed the behavior of a device that we didn't change the driver and therefore we didn't test by changing the device tree and rendered it non-functional without even knowing it. So that's just kind of a word of caution is every time you change these clock, pin marks, power supply, and probably some other things, you need to look at the whole device tree to see all what might use those devices. So there is hope about this. As I said, Mark Rutland's talk yesterday was kind of a disaster recovery. But I do think things are getting better. I'll talk a little bit about what we might do to preserve information and do updates with a few more files. One approach that was posted by Joel Fernandez, presented by him at the California ELC last winter, is the flattened image tree. So the flattened image tree is just a little file that describes a kind of a manifest that can record things like the versions of the device tree, the kernel, and any miscellaneous binary blobs, and the cyclic redundancy checks sums. So this is really handy. While I might wish that I did a good job of keeping records, this method of building an archive kind of has it all right there. Obviously, you could also use BitBake recipes or an Android-like repo XML manifest as well. But some type of build system that calls out all the files in one place is great because you know it actually built that way at some point in the past. The other nice thing about the flattened image tree is you have this short little ITS file, which has a syntax much like device tree, that you can compile with the make image usual tool and with the device tree compiler DTC. And it creates a single archive that you can use for an update that has all these files in them. Obviously, there are other ways to do this, but this one is really simple. And UBoot now has a facility for handling these flattened image trees. And thanks to contributions by Chrome OS, who uses this mechanism, there's now a facility for signing the flattened image tree archives. So as far as solving multiple problems at once about security, about doing updates as atomically as possible, and as far as preserving all this information, I think this approach is actually pretty attractive. So hats off to Google and to TI for making this available. It's something that a lot of people may want to look at. As far as I know, there is no ability to use this sign device tree blobs absent this flattened image tree. And someone at Google has told me that's really why in part they've adopted this approach. They want to have everything in the Chromebooks signed. So another as yet unmerged feature in the kernel that seems like it has some appeal for typical embedded problems is the implementation of runtime configurability via overlays. This is a contribution from Pantelus and Tonyu, who's been here this week and who some of you may know. Basically, right now, when you compile your device tree, you're making a binary file, which is in slash boot or on some auxiliary storage, and which is loaded by the boot loader and which is static. And so you can, for example, the flattened image tree have a multi-boot almost in the spirit of grub and load different device trees. But you cannot, at boot time, with U-boot easily, you can't change the device tree. I mean, it's a compiled file just like the kernel. And unlike the kernel, the device tree doesn't have modules that load. It's just static. So Pantelus's proposal is in spirit similar to having modules for the device tree, having fragments that can be loaded. So Pantelus created this facility to support the capes that go with the Beaglebone, which are these daughter cards that can plug in. So it gives a hot plug or kind of power on time configurability of the Beaglebone so you can attach different accessories to it. The Beaglebone recognizes its capes by reading an EE prom when the main controller gets an I2C event corresponding to the attachment of the cape. So clearly, this cape EE prom model is not going to apply to most of embedded. But if you look at the changes, well, if you look at the cape manager that Pantelus has created, which you can find links through his talk and his paper, which are both online. So these are hyperlinks in my presentation, all this highlighted text, by the way. And so you can pull his sources and try out this overlay for yourself. And for most use cases, you'll want to change the signal, which causes the kernel to load the fragment. Basically, you take some patches from Pantelus for the device tree compiler. And you can compile the short little plug-in files that he has several examples of into DTBOs, basically Device Tree Binary Object Files, which this cape manager that's watching for some trigger can then load and basically add to the device tree on a running system. So to me, as far as updates go, you could have a strategy similar to Union FS. If you're familiar with how NAPEX works, you get a writeable file system that the user can employ in a system that they're booting from unwriteable storage using Union FS. You could basically have a device tree binary in some ROM that you never change, that your golden fail-safe device tree binary, and you could just do updates via these overlays. I haven't really thought through whether that's a good strategy, but I would think for some cases, use cases, it might be. And then the third method of adding flexibility to the device tree and the kernel that seems kind of appealing was actually a nice talk yesterday about Zen on ARM. But the whole idea of using hypervisors to have collections of bootable images, and clearly then, if you try to boot one image and it doesn't come up, you can fall back to the old one. There's some ability here also to kind of preserve. You could have a long list of sets of files. It's just kind of a nice way of collecting information. And of course, there's a lot of ability with hypervisors to have a more secure system and to check signing of binary blobs and things like that. So whether or not you find Zen in particular appealing, a lot of people in automotive are going to hypervisors for security reasons. And this is another method maybe of both preserving information and managing the large perfusion of files we now are having. So what are some best practices for making the device tree more maintainable? Well, one that's been discussed a fair amount at the meeting is the device tree schema and using a validator with a device tree. As a matter of fact, Steven Warren of NVIDIA has been hard at work and has just posted last night some code for a validator to the mailing list. So the idea is just to, as you can easily do with web pages, any HTML or XML, you can have a kind of a DTD description that you can check if your device tree is valid. So that could involve, right now, the device tree compiler just kind of checks if your curly braces match or if there are any missing dependencies. It doesn't tell you, as Russell King was just complaining about on the mailing list, whether you've made a typo in the top level board file. The device tree compiler will just, device tree compiler doesn't have the level of checking that you're used to with C files. So there's a pretty large variety of mistakes you can make in it now. Not to mention just bad ideas, but actual mistakes that the compiler won't catch. And so a validator, as proposed by Perant and Kusan, would catch a lot more mistakes. I think we have a lot of opportunity with the validator. I was talking to Mark Rutland about this yesterday. But the validator could use a tree of schemata, I think the plural, as schema is Greek. And so we could have separate schemas, schemata, for different parts of the tree. And this would just be a way to make the burden of the maintainers who are reviewing device trees and the bindings a lot less, because they could just run the validator. It would allow people who are submitting upstream to make sure that they're kind of in keeping with the recommended device tree coding style. And it's an opportunity for the leaders of the various subsystems to express to the people who are creating device trees really what's acceptable in a way that is difficult now. And so if you did have a tree of schemata, then you might want to have the validator compile all of them into one top-level schema and compare that against your top-level device tree source. I was going to make a diagram of this to make it clear what I'm talking about. But basically, the validator would be enforcing the inheritance that's essentially going on in the device tree. There was a brief discussion on the mailing list about using XML as a schema language, which I was kind of surprised about. Lots of people like James Bottomley said good things about it. To me, that doesn't really make any sense, just because when I first looked at device tree, I was struck at how much like JSON it looks like. JavaScript object nucleation for those of you who have not heard of it. As a matter of fact, I thought it was JSON. This is just a little fragment of JSON right here. And you can see it's key value pairs, terminated semicolons, and side curly braces in a list format. Really, there is some question as to whether to describe properties in key value pairs in a tree, we need to create a new domain-specific language for the device tree. So the advantage of taking over JSON is that there's a huge, huge, huge number of visualization, validation tools. The device tree has been around for years now. It's got international language support. There are tools for it and C, C++. And the design of JSON, what its intention was to be a natural representation of data structures for the C family of programming languages. That is the problem we're solving. We are solving the problem for which this very popular, stable, well-supported solution exists. So I suspect that the train has already left the station about creating an entirely new tree structure format for device tree. But certainly, rather than pick XML, I would pick JSON, the fact-free alternative to XML, as its creator, Douglas Crockford, has called it. So just one more thing that's kind of a pet peeve of mine is what I would call premature optimization of the device tree. That is, if you think of the device tree include files as themselves a tree, there's no reason in the bottom-level file to make choices that can potentially break some of the top-level choices that you might make. In other words, if you have OMAP3, then OK. That's the fundamental choice for your platform. And I don't have any problem with saying OK, turning on the OMAP3 in your lowest-level include file. But if you have some peripherals that have resource conflicts with other peripherals and you only have them on some of your boards, please don't enable that peripheral in the bottom-level file. Please enable it in the top-most file where you know that you actually have that device and want to use it. It's just the idea that when you have a nested hierarchy of include files, you want to use that structure wisely and not put choices in the bottom-most files that are liable to create conflicts at the top. In particular, when you have a lot of these files and there's a choice that's bad for you in them, sometimes it takes a while just to figure out where it is. So the OK chosen and config on boot file options, those properties and the device tree nodes, are our configuration. They are choices. And unless there's really a good reason, like we're talking about the processor for the board, I would not put those in the bottom-level of the hierarchy. It's just liable to lead to trouble later on. So this is just a general argument about level separation, essentially. If you're going to have a board DTS file and a CPU DTS file, don't be putting choices about the data storage and the CPU one. And it is better to think of it those files that way. And hopefully, the validator may help enforce some of that good practice in the future. So a lot of the pain about device tree is related to tools in that the DTC device tree compiler is kind of new and not that featureful. It doesn't, for example, have a verbose mode. The problems I alluded to earlier of do my kernel configuration and my device tree enumerations match, there's no real tool to answer that. There's no real tool to do the reverse problem of, gosh, I have this binary that I like and that I want to change one thing in which of my 40 device tree source files do I compile to produce this. So that's why I suggested that we might want to use some of these manifests or recipes to preserve that information. On a booted system, we have no tool that reads slash proc to tell you what's in your device tree in case you wanted to know. Maybe if the device tree is really going to be an ABI, we can have that information in slash boot in a zip file like we have config.jz. There is an option, which is not in the def config for most arches, of exporting the device tree information to slash proc, but that's not on by default. So it would be great if we had visualization tools. And eventually we will need, I think, some type of facility for signing device tree blobs, which are not appended to the kernel, although that is at least a simple solution. So the tool that I've made for myself, because it solves an actual problem I have, is a script called Make DTS. This is just a bash script that runs the Cpre processor and runs the device tree compiler and produces source output just so you can read it and kind of get a sanity check. Given the structure of the device tree, if you make a mistake and your node gets in at the wrong level, usually when you look at the source, it's pretty evident. So that script is, this is just an example of it running. It produces an output file. This is x86, because I don't have the cross compilation tool chain on there. But this is the result of processing maybe sometimes 10 device tree source files and outputting it into one ASCII file that you can then read. So it resolves macros and compiles all the files together. There is a program called FDT, Flatten Device Tree Dump, that's in scripts in the kernel source directory. And that produces output much like that. But in that tool, these strings all come out as hex. And I find reading ASCII characters a little bit easier, especially when things are broken and I'm not sure what's wrong than reading hex. So this script is up at my website, shedevelop.com. My slides are also there. An older version of my slides without all these hyperlinks in it is at the Linux Foundation web page. It's also at slideshare.net, so anyhow. This stuff is all there if somebody wants it. It would be great if I also posted this to the mailing list. So this is a little bit, got a little bit more on it than this. This is a pretty humble thing, but it's useful, I think. It's useful to me for debugging. So I've got about two minutes left. It's really important for long-term maintenance to preserve the set of information of all the different systems, all the different files that go into your build system. And this requires maybe a little bit more thought and care now that we have the device trees, just one more thing. I think this Flattened Image Tree with a single archive for updates is really appealing and its ability to have every component signed and checked some is really a plus. And that's now part of UBoot, at least. The validator and maybe some other simple things like a verbose mode for the device tree compiler would really make life a lot easier. You can make your own life easier by having good practices regarding level separation and soon validation in the device tree. The overlays and maybe a hypervisor are appealing as safe ways to approach updates. And so device tree, according to Mark and many others, has been a disaster so far. And I think it has caused a lot of people pain. And maybe the worst doesn't quite over yet. But on the other hand, the whole concept of separating the detailed description of hardware from the abstract interface definition and the description of the methods that are used on the hardware is a good idea. I mean, that's a generally accepted, widely agreed software engineering practice. And so now we're finally abstracting the definition of the devices away from their configuration. And that's a good idea. So while the beginning of the device tree has been ugly, that's just because adding new features is always hard. And I think in the end, maybe in the imminent future, the device tree will actually end up saving work and making life easier, even though it's promised to do that has not yet been fulfilled. So maybe we have the disaster so far, but the happier future ahead. So with that, I've just about run out my time. If anybody has any questions, please pick up. So they tell me that either you can speak into the microphone or I'll repeat your question. Looks like it'd be easier for me to repeat your question. My idea of this is there's one thing I'd like to challenge because this means the idea of a firmware, whatever it means, put loader, of modifying the device tree in case when the hardware is changing, et cetera, et cetera, on its own. And that's the one thing I'd like to challenge because, hey, the device tree, Latin device tree, is a direct descent, it's a counts from the area of the open firmware architecture, where by definition, the device tree was actually constructed in runtime by firmware based on the real configuration hardware. And the other thing is that it's actually very easy to modify the firmware.  So it is definitely an option. So in case of your changing, because in one of the businesses, we'll have to update the device tree because the hardware has changed. And I'm perfectly fine with this. The device tree by definition is the description of the hardware. If the hardware changes, obviously you have to change the device tree as well, right? But it doesn't necessarily mean that it has to be somehow detailed by the kernel, or it doesn't necessarily mean that you will have to update the device tree load, which is there. It can be modified by firmware. Moreover, if the hardware by definition can change, maybe firmware should generate the device tree in the business. So the question is, what about some alternate methods of updating the device tree blob perhaps via firmware? There also was a very nice presentation yesterday. I thought by Darren Hart, talking about ACPI, kind of managed to convince me that that may be a viable alternative to device tree. For the most part, we just want things that work and are maintainable and stable. So yeah, I'm not, I confess, I don't really know how the power architecture and the spark have generated. They're using open firmware of their device trees from the actual hardware. I'm aware that they do that. But sure, yeah, I mean, if there's a way of easily extending that to other architectures, maybe that's the way to go. I do think it's pretty clear from the state of these things that we don't have it all figured out yet and that people have to have open minds going forward. So does anyone else have any questions or any violent objections? Or yes? So the remark was that there are no comments in JSON. And so we'd have to deviate from the JSON standard if we wanted to have comments in the device tree, which I think everyone agree is probably a good idea. Yeah, I mean, I suppose the device tree might want to modify JSON if anybody really took a hard look at using JSON as opposed to creating a new domain-specific tree description language. But JSON has a plug-in model and things like that. JSON is already diverse and has all kinds of files on it. So I don't know. The question is, would that be easier and better in the long term? I mean, the great thing about JSON is we'd get all these visualization and validation tools for free if we used it. So that would be nice. Fair enough. I mean, the comment was that we're not getting it for free if we have to change anything. But we're at a moment when we're sort of contemplating changing things anyhow. So that's why it's worth approaching the possibility just because the changes wouldn't be very large.  But yeah, maybe it wouldn't be worth it. Or maybe we want to go. Seems like the idea of using XML hasn't exactly caught fire. But I think there's general agreement that adopting one of these other choices wouldn't be ridiculous. Anybody else have any? Yes. Device wit, I'm sorry? Configuration. Oh, yes. So the question is if device configuration shouldn't go in the device tree, where should it go? And that's something that was discussed a little bit at Mark's talk yesterday. The way I look at this from an embedded perspective is, well, we don't want device configuration in board files. And we don't want it in device tree. It's just clear they don't want it. The people who are real software purists are like, we hate this hardware. It's so messy. Just get rid of it. We'll just write everything on some glorious virtual machine without hardware. What was this thing? Thank you. That Mark showed yesterday, Linux dummy vert.  Just band it all together, right? So at one point, I think there was a proposal on April Fool's Day to get rid of slash art, right? That's essentially what we're talking about. So yeah, I mean, wherever we put hardware configuration, the grown-ups who are in charge of this whole system get annoyed by it.  They're not board files. No, they're not. And they won't be in the directory where the board files are. But yeah, I think everybody basically agrees that somewhere this information, there has to be hardware configuration somewhere. But if the device trees are an EBI, then I guess they can't be in the device trees. So the message we're getting in all seriousness is that the configuration cannot be in a place where user space or other binary interfaces expect it to be stable. It has to be kept internally to the kernel and not exposed in any binary format because otherwise people will depend on it and they will be angry when their files stop working. I guess that's kind of where we are. So that seems sensible enough. But yeah, there is a question now, where does the configuration go? So does anybody have a? Yes. You just have just a separate piece to clear that unlike the device tree, this is configuration. And this is not to be touched by the Google and thus it can be done in the kernel. So the comment is that some of the virtualization schemes have an explicit configuration file which no one is supposed to read unless they're the owner of that file and that people are sternly warned is not being exported to user space and is just the private file of the hypervisor, I guess. So the comment is just that you have to be very careful about interdependencies that you're kind of coding in between the bootloader and the firmware and the kernel because then there's really no update scheme that really is going to be robust at all. So I think I'm basically out of time unless someone has one final quick question. So thanks very much for coming.


We're cruising on today through the workbook, practicing our daily lessons, and rejoicing every step of the way, that's it. And today we're gonna be going into lesson number 41, workbook lesson number 41. And it's God goes with me wherever I go. I've always said, the mind goes with you wherever you go. So pay attention to your thoughts, because the body may seem to move around, but your mind goes with you wherever you go even more. So the divine mind, the mind of God, you live and move and exist in the mind of God. So no matter where the body or the projection, wherever the puppet seems to be going, your mind is always there with you. God is always there with you. And hence lesson 41, God goes with me wherever I go. Today's idea will eventually overcome completely the sense of loneliness and abandonment, all the separated ones experience. Depression is an inevitable consequence of separation. So our anxiety, worry, a deep sense of helplessness, misery, suffering and intense fear of loss. The separated ones have invented many cures for what they believe to be the ills of the world. But the one thing they do not do is to question the reality of the problem. Yet its effects cannot be cured because the problem is not real. The idea for today has the power to end all this foolishness forever. And foolishness it is, despite the serious and tragic forms it may take. So how beautiful Jesus is reminding us that there aren't any magical solutions in the world because the world is a projection of error. And the error itself, the belief in separation from God, the separation from the Creator is not real. And if the error is not real, then the effects, the seeming effects of the error, which are all the projections of the world, they're not real either. So yeah, God goes with me wherever I go. This is reminding me of our earlier lessons, lessons 29 and 30. God is in everything I see. It's 29 and 30 was, God is in everything I see because God is in my mind. Yeah, you can see we're building today on lesson 41 from those earlier lessons. God goes with me wherever I go. We're training our mind to remember God. That's the whole purpose of everything is to remember God. There is nothing else but to remember God. And when you remember God, you sing a happy tune because there's lots to be grateful for in being a perfect creation of a perfectly loving God. And that's what the Christ spirit is. Yeah, that's what the I am presence is. So we'll go on with paragraph three here in lesson 41.  It will cure all sorrow and pain and fear and loss because it will heal the mind that thought these things were real and suffered out of its allegiance to them. You can never be deprived of your perfect holiness because its source goes with you wherever you go. You can never suffer because the source of all joy goes with you wherever you go. You can never be alone because the source of all life goes with you wherever you go.  We understand that you do not believe all this. How could you when the truth is hidden deep within under a heavy cloud of insane thoughts, dense and obscuring, yet representing all you see. Today we will make our first real attempt to get past this dark and heavy cloud and go through it to the light beyond. There will be only one long practice period today. In the morning, as soon as you get up, if possible, sit quietly for some three to five minutes with your eyes closed. At the beginning of the practice period, repeat today's idea very slowly. Then make no effort to think of anything. Try instead to get a sense of turning inward past all the idle thoughts of the world. Try to enter very deeply into your own mind, keeping it clear of any thoughts that might diverge your attention. From time to time, you may repeat the idea if you find it helpful. But most of all, try to sink down and inward away from the world and all the foolish thoughts of the world. You're trying to reach past all these things. You're trying to leave appearances and approach reality. It is quite possible to reach God. In fact, it is very easy because it is the most natural thing in the world. You might even say it is the only natural thing in the world. The way will open if you believe that it is possible. This exercise can bring very startling results, even the first time it is attempted. And sooner or later, it is always successful. We will go into more detail about this kind of practice as we go along, but it will never fail completely and instant success is possible. Throughout the day, use today's idea often, repeating it very slowly, preferably with eyes closed. Think of what you're saying, what the words mean. Concentrate on the holiness that they imply about you, on the unfailing companionship that is yours, on the complete protection that surrounds you. You can indeed afford to laugh at fear thoughts. Remembering that God goes with you wherever you go. Precious, precious. God goes with me wherever I go. And in support of this lovely lesson, I'm going to go to chapter 27 and to section eight, the hero of the dream. And this section is so, so helpful, putting everything into context. Because with our lesson today, God goes with me wherever I go. We are releasing our mind from images that it has believed in, thought forms that is appearances that has been invested in, and we are approaching reality. So this section, chapter 27, section eight is the hero of the dream. It's really showing us that we are more than the body and that we are free when we remember this. We are not a dream figure in the dream of the world. We are the dreamer of the dream. And the body is the hero of the dream. But the hero doesn't have a reality, doesn't have an existence. Yeah, a little bit later here, less than two hours from now, I'm going to show a movie on Tribe of Christ. And yeah, this is the section that really has been coming to me very strong today. For our movie session in Tribe of Christ, a free movie session. So I'm going to go through it here in support of our workbook lesson today. God goes with me wherever I go. The body is the central figure in the dreaming of the world. There is no dream without it, nor does it exist without the dream in which it acts as if it were a person to be seen and be believed. It takes the central place in every dream, which tells the story of how it was made by other bodies, born into the world outside the body, lives a little while and dies to be united in the dust with other bodies dying like itself. In the brief time allotted it to live, it seeks for other bodies as its friends and enemies. Its safety is its main concern. Its comfort is its guiding rule. It tries to look for pleasure and avoid the things that would be hurtful. Above all, it tries to teach itself its pains and joys are different and can be told apart. The dreaming of the world takes many forms because the body seeks in many ways to prove it is autonomous and real. It puts things on itself that it has bought with little metal disc or paper strips, the world proclaims as valuable and real. It works to get them doing senseless things and tosses them away for senseless things it does not need and does not even want. It hires other bodies that they may protect it and collect more senseless things that it can call its own. It looks about for special bodies that can share its dream. Sometimes it dreams it is a conqueror of bodies weaker than itself, but in some phases of the dream it is the slave of bodies that would hurt and torture it. The body's serial adventures from the time of birth to dying are the theme of every dream the world has ever had. The hero of this dream will never change nor will its purpose. Though the dream itself takes many forms and seems to show a great variety of places and events wherein its hero finds himself, the dream has but one purpose top in many ways. This single lesson does it try to teach again and still again and yet once more that it is cause and not effect and you are its effect and cannot be its cause. So that is the single lesson that the hero is trying to teach and reinforce that he teaches it and tries to teach it still again yet once more, that it, the world is cause and not effect and that you are its effect and cannot be its cause. So you can see this is an impossible lesson to learn. Any mind that is trying to learn this is going to be conflicted, is going to feel split, it's going to feel unhappy, it's going to feel angry, it's going to feel shame and guilt because the world is the effect and the mind is the cause and when you join with the Holy Spirit and Jesus you open yourself up to the capital C cause, God. And God is in mind and Christ is in mind. Christ is an idea in the mind of God and therefore to look to this world and believe that it causes anything that it means anything, that it shows you something of substance is insanity. Purgatory four, thus are you not the dreamer, but the dream. And so you wander idly in and out of places and events that it contrives, that this is all the body does is true. Where it is but a figure in a dream. But who reacts to figures in a dream unless he sees them as if they were real. The instant that he sees them as they are, they have no more effects on him because he understands he gave them their effects by causing them and making them seem real. How willing are you to escape all effects of all the dreams the world has ever had? Is it your wish to let no dream appear to be the cause of what it is you do? Then let us merely look upon the dream's beginning for the part you see is but the second part whose cause lies in the first. No one asleep in dreaming in the world remembers his attack upon himself. No one believes there really was a time when he knew nothing of a body and could never have conceived this world as real. He would have seen at once that these ideas are one illusion, too ridiculous for anything but to be laughed away. How serious they now appear to be. And no one can remember when they would have met with laughter and with disbelief. We can remember this if we would look directly at their cause and we will see the grounds for laughter not a cause for fear. Okay, there's a lot in that paragraph. So in other words, to believe that people cause things, that the environment causes things, that the past causes things, to look for causation in form is to see something that's not there. There are no causes and there are no effects in form. That's the big trick. And basically Jesus is saying, then let us merely look upon the dreams beginning for the part you see is but the second part whose cause lies in the first. So the self-concept is like a two-tier concept and what is perceived as the world, the external world, which really is an external, what is perceived as the external world is the dream that you gave away.  But this is not the case. This is a total distortion of perception. It's like saying that you're a body or a person and that you're at the mercy of external effects. If that was the case, then victimization, abuse, mistreatment would all be possible. If that was the case, then you could use the images of the world to reinforce the case that you are at the mercy of something that's not you, that there's a will outside of you that's doing something to you that you don't like. But none of this is true. No one asleep and dreaming in the world remembers his attack upon himself. So no one consciously is aware of the belief in separation. That's what the attack upon himself is, the beliefs you can separate from your creator. That's a belief in the mind. The ego is a belief in the mind. And that is pushed out of awareness as is the light that is even still deeper than that belief in attack. It's the light of truth, the light of oneness, the light of God, the light of Christ. And in that light of Christ, you would see that there's only love and there is nothing else. But as he told us, no one believes there really was a time when he knew nothing of a body that could never have conceived this world as real. He would have seen at once that these ideas are one illusion too ridiculous for anything but to be left away. How serious they now appear to be. And no one can remember when they would have met with laughter and with disbelief. We can't remember this if we've looked directly at their cause and we will see the grounds for laughter, not a cause for fear. So here we go. Let us return the dream he gave away unto the dreamer who perceives the dream as separate from himself and done to him. Into eternity where all is one, there crept a tiny mad idea in which the Son of God remembered not to laugh. In his forgetting, did the thought become a serious idea and possible of both accomplishment and real effects. Together we can laugh them both away and understand that time cannot intrude upon eternity. It is a joke to think that time can come to circumvent eternity, which means there is no time. A timelessness in which time is made real, a part of God that can attack itself, a separate brother as an enemy, a mind within a body, all are forms of circularity whose ending starts at its beginning, ending at its cause. The world you see depicts exactly what you thought you did, except now you think that what you did is being done to you. The guilt for what you thought is being placed outside yourself and on a guilty world that dreams your dreams and thinks your thoughts instead of you. It brings its vengeance, not your own. It keeps you narrowly confined within a body, which it punishes because of all the sinful things the body does within its dream. You have no power to make the body stop its evil deeds because you did not make it and cannot control its actions nor its purpose nor its fate. Of course Jesus is being sarcastic here, tongue in cheek because the body is just a symbol and as he's told us in his text, what you do comes from what you think. And when you basically believe you have no power to make the body stop its evil deeds because you did not make it, it's basically just believing that something external to the mind is causative and that you're an effect of this external cause. Jesus is gonna remind us the kingdom of heaven is within and there is nothing outside you. You are love, you are light and you must give up this crazy belief in externals, in images. My thoughts or images I've made, you have to relinquish the ego, the image maker because it's not a creation of God. God is abstract and eternal love is abstract and that's what the IM presence is. The world but demonstrates an ancient truth. You will believe that others do to you exactly what you think you did to them but once deluded into blaming them, you will not see the cause of what they do because you want the guilt to rest on them. How childish is the petulant device to keep your innocence by pushing guilt outside yourself but never letting go. It is not easy to perceive the jest when all around you do your eyes behold its heavy consequences but with their trifling cause. Without the cause do its effects seem serious and sad indeed, yet they but follow and it is their cause that follows nothing and is but a jest. So the ego is the false cause, the ego follows nothing, it wasn't created. It doesn't have an existence but if you believe in it, then you behold the unreal effects of this unreal cause and as Jesus is saying, its effects seem serious and sad indeed but that's just because they're believed to be real. Paragraph nine, in gentle laughter does the Holy Spirit perceive the cause and looks not to effects. Looks not to effects. The Holy Spirit looks not to effects. It's not interested in the outcomes of the world. It's not interested in the images. Just using the images to see that it's all simultaneous, it's all one. It's all singular. That's awakened awareness, that's the happy dream. The happy dream, that's the forgiven world. How else could he correct your error who have overlooked the cause entirely?  You judge effects but he has judged their cause. Yes, we know that, he has judged their cause as unreal. And by his judgment are effects removed. Perhaps you come in tears but hear him say, my brother Holy Son of God, behold your idle dream in which this could occur. And you will leave the Holy instant with your laughter and your brothers joined with his. The secret of salvation is but this, that you are doing this unto yourself. No matter what the form of the attack, this is still true. Whoever takes the role of enemy and of attacker still is this the truth. Whatever seems to be the cause of any pain and suffering you feel, this is still true. For you would not react at all to figures in a dream you knew that you were dreaming. Let them be as hateful and vicious as they may.  This single lesson learned will set you free from suffering. Whatever form it takes, the Holy Spirit will repeat this one inclusive lesson of deliverance until it has been learned. Regardless of the form of suffering that brings you pain, whatever hurt you bring to him, he will make answer with this very simple truth. For this one answer takes away the cause of every form of sorrow and pain. The form affects his answer not at all, for he would teach you but the single cause of all of them, no matter what their form. And you will understand that miracles reflect the simple statement, I have done this thing and it is this I would undo. Bring then all forms of suffering to him who knows that everyone is like the rest. He sees no differences where none exist and he will teach you how each one is caused. None has a different cause from all the rest and all of them are easily undone but by a single lesson truly learned. Salvation is a secret you have kept but from yourself. The universe proclaims it so, yet to its witnesses you pay no heed at all, for they attest the thing you do not want to know. They seem to keep it secret from you. Yet you need but learn, you chose but not to listen, not to see. How differently will you perceive the world when this is recognized? When you forgive the world your guilt, you will be free of it. Its innocence does not demand your guilt, nor does your guiltlessness rest on its sins. This is the obvious, a secret kept from no one but yourself and it is this that has maintained you separate from the world and kept your brothers separate from you. Now need you but learn that both of you are innocent or guilty. The one thing that is impossible is that you be unlike each other, that they both be true. This is the only secret you have to learn and it will be no secret you are healed. So, we are really, really seeing that that is why God goes with me wherever I go because God is the perception of a forgiving world, a happy dream. Only the loving thoughts are true and this is what forgiveness beholds. Only the loving thoughts are true. Jesus says, dream softly of your sinless brother. Remember his kindness is instead of the hurts that he gave. It's only attack thoughts and the filter in the mind of attack thoughts that is the ego and when you look through the ego or with the ego or through the ego's filter, you behold a world of separation and this is a fearful state but it's not real. It's a hallucination of fear and yet today's lesson takes us inward, inward into that beautiful love and light in our heart. God goes with me wherever I go. That's a happy song. God goes with me wherever I go. That's something to repeat but as Jesus said, it's just be quiet today, close your eyes, sink deep into the stillness. Allow yourself to feel that love, feel completely embraced and surrounded by that love. That is God's love and you cannot fail because God goes with you wherever you go and it's adorable that the light of God is shining in us and as Jesus says, it's waiting to radiate through us and out into the world. Ooh, that should give you happy shivers. Love is ready to radiate through you and out into the world and that is our purpose today to be the bringer of light. So thank you. Thank you so much for joining me. If you get a chance, please come in to Tribe of Christ and join me for the movie. It's probably about an hour and 15 minutes away from start time and if you're not signed up for Tribe of Christ, there's so many brothers and sisters all over the world that want to interact and shine their light and rejoice together and support one another and nurture one another and that is worth going into Tribe of Christ and registering and then every two weeks we just have a movie to dive deeper together into this deep love and into the experience of a forgiven world of a happy dream where we dream softly of our sinless brothers and sisters. Yeah, we need to dream softly. Enough of harsh dreaming. Enough of playing the blame game. Enough of pointing the finger. It's time to dream softly of our sinless brothers and sisters. Okay, thank you everyone. Thank you for joining me. God bless you. See you at the movies.


So welcome everybody to week two of our virtual RSP Seminar series. We're very happy to have our first Judy Slee seminar today. So this was scheduled for semester one, but with postponed due to the current context. So it's my pleasure to welcome Erin Parker, who is the theme convener for our Judy Slee series. First of all, I'll turn to Michaela. She's just going to highlight some housekeeping for everybody. And then we'll hand over to Erin to introduce that wonderful speaker today. So thank you everybody and I hope you enjoy. Hi everyone. Thank you for joining the psychology seminar series. So yeah, just a few housekeeping rules. Just a reminder that this seminar is being recorded and will be available on the psychology events page and will also be sent by email. Upon entry of the webinar, you will be muted and we ask that you please stay muted for the duration of this seminar. If you have any questions, you can write them in the question box below at any time and we'll have question time at the end. Thank you and I'll hand off to our theme convener, Erin Parker. Thanks Michaela. Hi everybody. Thanks for coming today. Very exciting to have our first student speaker of the year actually because Neve was meant to speak earlier in the year, but we had to cancel that seminar right as the university went into lockdown. So I'll just start by acknowledging the traditional custodians of the land that some of us are on today. Some of us may not be the Ngunnawal people and pay our respects to the elders past, present and emerging and obviously welcome any Aboriginal or Torres Strait Islander people that are here with us today. So very exciting to have Neve presenting as I said. Neve's research is in cognitive psychology and she's going to tell us a bit about that in general today as well as present on the results of one of her studies. So whenever you're ready Neve, I'll hand over to you to start. Okay, great. Thanks Erin. I'll just share my screen. Can everyone see that? I'm going to receive you. Okay, great. Okay. So hi everyone. My name is Neve Campbell and I'm a second year PhD student. I'm supervised by Stephanie, Mark and Amy. And today I'm going to be talking to you about what I've been working on over the past one and a half years and ultimately answering the question, does motivational intensity exist distinct from arousal and valence? So we all experience emotions and these emotions colour and flavour our everyday lives. However, the relationship between different aspects of emotion remains poorly understood. So originally emotions exist on two dimensions. The first is called arousal, which ranges from calm to aroused. And the second is called valence, which ranges from unpleasant to pleasant or negative to positive. Now when emotional picture stimuli are plotted on these two dimensions, it looks like this, which we call a U shape. So where do different emotional picture stimuli exist on this U shape? So for example, pictures of cute little puppies, these are obviously quite pleasant, but receive medium arousal ratings. Pictures of erotica and extreme sports, these are pleasant as well, but higher in arousal. And on the other end of the valence spectrum, there's pictures that depict sadness, which are quite unpleasant, but lower in arousal and then pictures of mutilated bodies and threatening animals. Obviously quite unpleasant and highly arousing and neutral stimuli. So these belong in the middle of the valence dimension, but they actually receive the lowest arousal rating. So they belong down here. So there's numerous theories that predict the relationship between emotion and cognitive scope. So how do we measure arousal and valence? And how has it been measured in the literature? So one really popular image database is the International Effective Picture System, the IAPS. So this is just a collection of a diverse set of picture stimuli, which have been rated on arousal and valence. And these ratings have been validated by physiological measures. So this is really good for valence and arousal. So there's been numerous theories that predict the relationship between emotion and cognition, in particular the broadening and narrowing of cognitive scope. So some of these theories are arousal-based. So they claim that arousal is the driver of the broadening and narrowing of cognitive scope. And some other theories are valence-based. So these claim that valence is the driver of the broadening and narrowing of cognitive scope. And this includes the famous broaden and build hypothesis. So more recently, the motivational intensity model has been introduced. So this claims that it's not about arousal or valence, but it's about the motivational intensity. So your strength of your urge to avoid or approach a stimulus, which drives the broadening and narrowing of cognitive scope. So I'm just going to give a little example on how motivational intensity is different to valence. So for example, these two pictures, which represent amusement and desire, they both are quite positive. But the motivational intensity model would predict that these have different levels of motivational intensity. So amusement has lower approach motivational intensity and desire has higher approach motivational intensity. And so this model would predict that these two different emotional states would have differing effects on the broadening and narrowing of cognitive scope. So this model has been quite influential throughout the field. So there's been links between motivational intensity and attentional breath, memory, time perception, cognitive categorization and attentional flexibility. But before we wanted to apply this model to our own research, we wanted to look at how has motivational intensity been operationalized in the literature. And this is what we found. So motivational intensity has been operationalized based on researchers intuition, whereby they've just made assumptions about where emotions exist on this dimension of motivational intensity. They've also used arousal as a proxy for motivational intensity, whereby, for example, they've taken ratings from the IAPs of arousal and use these to represent motivational intensity. And they've also used measures of discrete emotions. So for example, they'll ask participants, how sad do you feel in response to this picture? And then they'll make predictions about where sadness exists on the dimension of motivational intensity. So overall they've made a few untested assumptions about where emotions exist on the dimension of motivational intensity. So the main issues with this model is that it claims that motivational intensity is distinct from arousal and valence. And also probably the big one is that they've never explicitly collected ratings of motivational intensity on a diverse set of picture stimuli. And that means that they haven't been able to compare it with arousal and valence. So that leads us to the research question of my first study of my PhD, which was, does motivational intensity exist distinct from arousal and valence? So what did we do? We created a picture rating study. So we had participants rate 300 pictures, and this was a between subject study. So we had three groups, and it's one rated on valence, one rated on arousal and another rated on motivational intensity, but the same 300 pictures. So the first question that we set out to answer was, is there appropriate professional intensity? So as I mentioned before, we had one group of participants rate those 300 pictures on the arousal scale, so ranging from calm to aroused. And then we had a second group of participants rate those same 300 pictures on motivational intensity, ranging from avoid to approach. So as I mentioned before, arousal has been used as a proxy for motivational intensity. So they would, the model would predict that motivational intensity and arousal have a moderate relationship. So now how I'm going to walk you through this data is we wanted to analyze avoidance motivational intensity and arousal separately to approach motivational intensity and arousal as well. This is because if arousal is going to be a good proxy for motivational intensity, then it should be related to both avoidance and approach motivational intensity. So if you just look at the left side of the screen, we're just going to look at avoidance motivation and arousal first. And so here's the prediction line and this is what we found. So it was a pretty good strong relationship. So that's good for avoidance motivation and arousal. But if you look on the right side of the screen, this is what we found for approach motivation. There was no relationship. So overall, is arousal an appropriate proxy for motivational intensity? No, if you were to use a proxy for motivational intensity, it should probably not be arousal. So let's just break that down as to why. So as I said, yes, avoidance motivation and arousal were related. So that means arousal is a good proxy for avoidance motivation, but not for approach motivation. So overall, not a good proxy. Okay, so as I mentioned, the original theories are valence based. So we also wanted to test whether motivational intensity is distinct from valence. So we had a third group of participants rate those 300 pictures on valence. And then just to refresh your memory, we compared that now to the motivational intensity scale and those ratings. And this is what we found. So we found a very, very strong relationship between motivational intensity and valence. So what does this tell us? Is motivational intensity distinct from valence? So results would suggest that motivational intensity and valence are very closely related. So this almost, it brings up the question as to whether motivational intensity is distinct from valence at all. So what are the takeaways from today? Arousal is not an appropriate proxy for motivational intensity. And motivational intensity might not be distinct from valence. And this has real implications for the relationship between emotion and cognitive scope because all that research that had been completed on the relationship between motivational intensity and cognitive scope could have really been valence that was doing the driving there. So what's next? We're actually going to be doing a follow-up study where we're going to be creating a behavioral measure of motivational intensity and valence and comparing the two. Yeah. So thank you to my supervisors, Stephanie, Mark and Amy for all your help. It's been really great working with you and also to the visual cognition lab and also all the friends that I've made at RSP. And if you'd like to follow me on Twitter, that's my handle. But yeah. Any questions? Thanks so much for listening. Thanks so much, Neve. That was great. One thing that I forgot to mention at the start, everybody was that we were having a short seminar today. Usually these seminars, we will have two people presenting, but I had a bit of difficulty getting a second presenter for today. So we've got plenty of time to have some questions for Neve. So if you can type your questions in the Q&A section, then I can read them out. Or Neve, you can read them if you want, because I think you can access them too. I can read them here. Yep. Okay, excellent. So do you want to read the question out and then give us your answer? Yeah. So I've got a good question here, which is, do you ever want to approach something with a negative valence? So according to the research, yes. There's been a lot of research on anger as the main emotional state that obviously is negative valence, but you want to approach. And we're going to test this in a follow-up study where we're going to be looking at whether there's any differences between motivational intensity and valence for anger after using the rating scale. Because in the research, they never operationalize motivational intensity. So that's what we're going to do. Can you please elaborate more on the behavioral measure that you will be using for your follow-up study? Okay. So it's still in the process of being created, but from what I understand, it's going to be an RT measure where we have participants complete two conditions. One for motivational intensity, one for valence, and we're going to show them all the images, and they're going to respond either avoid or approach or negative or positive. And then we'll look at the RTs for these and rank order them. And hopefully if there is no difference between motivational intensity and valence, then we'll also see a really strong correlation. But this has only been created recently. So we're still in the process of discussing it. Are there any more questions? I have a question. I just can't type it in the box, but I see ones just come through. My question is actually what are you hoping at the end of your PhD that you will be sort of the applied outcomes? Like what do you want to see coming out of your research at the end? That's a good question. So the original, like my original research question was looking at emotion and cognitive scope. So I really would, but then it turned because we were looking at the literature and realized that motivational intensity have never been operationalized. So we've more been focusing more on the emotion side so far. So at the end, I really would like to probably determine, especially looking at whether valence is the driver of cognitive scope and probably more looking at the effect on cognitive scope as well. That's what I'm thinking. But I guess, yeah, I'm still thinking about what my end goal is in all honesty. Cool. Thank you. Okay. So, but it seems that the target of anger will be important. I can be angry at historical injustices. Well, might want to I approach, I can be angry at you and want to approach you. Basically, my point is that you might find different types of findings as a function of the type of angry inducing picture you present, which means that there is a third variable at play. Yes, this is a good point. So in our new study, which I haven't explained, we're actually trying to find the best. We're doing it like a pilot study, I guess, where we're trying to find the best stimuli that represent the different emotions that we're interested in. And one of them is anger. So that's what we're running at the moment. We're presenting a lot of different pictures that might be angry, like represent anger to different participants and will be selecting the pictures that get the highest ratings on anger to go into the next study. I don't know if that answers the question. But yeah, sort of. That's okay. We can talk about it later if you want. We can actually get Michael unmuted too. And that way you can answer the question. You can ask the question verbally, Michael. Where is he? I don't know how to get it. Michaela will give you. Yeah, Michaela. I've just given you controls, Michael. Okay, can you hear me? Yeah. Can you? Yeah. Yeah. No, that's so I'm just I'm just kind of pushing the point just for just for the sake of it. Yeah. I can imagine you doing a pilot test and getting and showing, you know, both a historical injustice and interpersonal violation, I suppose, and they both invoking equal amounts of high intensity anger. And then you including both of them in the in the final study. I suppose to me if isn't, I would want to in the interpersonal violation, I would want to the anger might lead me to approach you. I guess I guess the issue for me is it's not apparent it's not self evident to me. Anger is an it has an approach motivation associated with it. I can imagine when it does. And I can imagine when it doesn't, even though they're equal intensity anger feelings, which means that there's something else going on here. Maybe. I don't actually know. Well, no, I think I'm trying to think why would I want to approach you, for example, if I'm angry. Well, I would want to approach you to somehow rectify it to invoke to to to write a wrong to tell you how pissed off I am or something like that to seek vengeance or to whatever. But if I'm angry at a historical injustice, I might want to approach somebody or I might just wallow in my anger because there's really no, I don't know what I would approach. Hmm. And so I do think and yet they can be both highly intense anger. So it's not. It's a if. Yeah, so I'm just, I do think it's really the negative emotion approach condition is it is a challenging one, I think for you. That's all I want to say. No, I definitely agree. It's definitely going to be a challenge. I think we're still trying like we've thought about all of these things as well and had many discussions on the confusion of anger. And, um, but yeah, I guess that's why we're going to test it or try our best to. Yeah, cool. Any other questions from anyone. I'll ask another question me. Okay. What are the other just out of curiosity. What are the other emotions that you'll be focusing on in that follow up stone. Okay, so that. Okay, so there's, there's five emotions that we'll be studying focusing on sorry. I think I actually have another slide from my TPR on this, but I probably don't need it. Um, there's five emotions. So there's three from the literature already that have been shown that there might be divergences between motivational intensity and valence. So those are all like as in a w e the emotion, um, anger and what was the third one. Amusement. So those are the three in the literature and then to in our study where we found minor divergences was desire and sadness. So desire, for example, um, people wanted to approach these on a sorry for the erotic stimuli, people didn't want to approach these, but they found them positive. For example, with the sad pictures, people wanted to approach these, but they found them negative. So that's just two examples. Thank you. What could be interesting practical implications of your findings. Um, can you elaborate more on this what what like what in terms of looking at cognitive scope or Diana. I think talking's permitted permitted. Oh, don't have a microphone. Oh no. I guess the real implications. I'm not really sure about practical implications. Um, but the real implications are I guess on cognitive scope as I mentioned, it could be valence extremities of valence. After all that was driving narrowing and broadening just photos that you use or do you use videos as well. Yeah, that's a good question. So at the moment we've only used photos but people and I'm sure we probably will try in the future to use videos or you can use emotional recalls or you can try and induce people into emotional states by reading little blurbs and Yeah, blurbs and stuff about different kind of experiences. But yeah, we're just trying to test pictures at the moment. So with that follow up study, if that pilot test if we can't get because at the moment we're measuring the discrete emotion. So for example, how angry does this make you feel if we can't get enough stimuli from that then we might like say for example with anger. A lot of the time, not really sure how possible it'll be to get angry from pictures. So we might need to use films or something else for that. I guess if there's no more questions we can probably finish it sure. Hi, Aaron. Yeah. Thanks. Is there more? I guess you can. A minute ago you mentioned the Q&A box. Um, no, there haven't. That's my internet. Yeah. Um, no, there hasn't been unless, nope. There's none. So it's open answered dismissed. It's like Aaron might be having some issues with her internet. So it sounds like there's no more questions. So I will just speak on behalf of Aaron. I think you did a wonderful job me and I think you engage with those questions really well. It sounds like you've got a really interesting research project and program ahead. And we would love to have you back to share. How you go with your next project? I'll sign you up for 2021. Yeah, I'll come back. Um, so I wanted to say thank you very much. Um, and if anybody has any further questions or comments, I'm sure me would be very happy for you to contact her and further that conversation. Um, as we go forward. So I think we can leave it there and thank everybody. We hope you have a lovely rest of your lunch. Um, and we look forward to seeing you next week. We have a presentation featuring Dr Amy Dall and Liz Miller that we all have. We're all looking forward to. So from the cognitive theme. So have a lovely day everybody and thank you very much. A big virtual clap for you. Um, and we wish you all the best for the next week everyone. Thanks so much everyone.