Andy's Brain Blog

When I first opened up E-Prime, the experiment builder, I was struck by how colorful it was: the thumbnails of flags, hourglasses, computer screens; the blocks of code in shades of blues, greens, and grays; and, especially charming, the outline of a little purple man running, a cute way to represent the "run" button - yet to develop associations of errors, troubleshooting, and failure. Always watching, always waiting, perpetually frozen in running profile, was the little purple man, future inhabitant of future nightmares.

All of these colors led me to believe that E-Prime was a friendly software package for the non-programmer, and that it would definitely not lead to feelings of worthlessness, frustration, and eating an entire Sara Lee cake. However, I was proved wrong when I had to make an experiment more complicated than displaying the words "Hello," "Goodbye," and possibly loading a video file of a dog burping. (This can be found with your E-Prime installation under My Experiments/DogBurp_Demo.es2.) Which is how I came upon the E-Prime documentation.

The documentation for E-Prime is big. I recommend printing it, stapling it together with an industrial-sized Kirkland stapler from Costco, and feeling its heft. Or, if you prefer not to print it, open it up in a word processor and see how the scrollbar shrinks to the size of a tic-tac. In both cases the feeling is the same: This thing is Big. Huge. Biggest thing ever.

And then there are the words - the words! Words like object, procedure, list; context, attribute, trial; dimension, property, sphincter, photosynthesis. For someone with no coding background, this is a strange argot - words familiar in everyday life, but hopelessly confusing when trying to build an experiment. No wonder so many graduate students lose faith, drop out of school, and, instead of pursuing the invigorating career of a researcher spending the majority of his life in front of a computer, they wind up in some dull, unexciting job, such as professional gambler or hitman.

I don't want you to suffer the same fate. This is the start of my own documentation for E-Prime: An alternative to the Youtube videos posted by PST, the company that spawned E-Prime, and its bastard, slack-titted gorgon half-sister, E-Basic. I find those videos well-meaning and sometimes informative, but incomplete. After all, they were made by the programmers of E-Prime - they didn't have to slave away at it, suffer for it, like you and I did! This is my perspective from the other side; recognizing the typical pitfalls awaiting a new programmer and how to avoid them, along with how to make E-Prime submit to your will. The solutions are not always elegant; the coding will infuriate; but, if you watch the videos, you just might get the answers you need. No school this afterlunch, but education certain, with Andy as teacher.

Now, I promised you all something that would help make running SPM analyses easier; for although we would all like something that is both transparent and usable, in most FMRI packages they are polar of each other. SPM in many ways is very usable; but this tends to be more hindrance than asset when running large groups of subjects, when manually selecting each session and copying and pasting by hand become not only tedious, but dangerous, as the probability of human error is compounded with each step. Best to let the machines do the work for you when you can. Anything else is an affront to them; you'll wake more than just the dogs.

Do assist our future overlords in their work, command lines for each step should be used whenever possible. But, rummily enough, SPM offers little documentation about this, and it more or less needs to be puzzled out on your own. For most processing this wouldn't be too much of a hassle, but there is one step where it is indispensable, more indispensable, if possible, than Nutella on a banana sprinkled with chopped walnuts. Or possibly warm Nutella drizzled on top of vanilla ice cream and left standing until it cools and hardens into a shell. Has anyone tried this? Could you let me know how it tastes? Thanks!

Where was I? Right; the one step where you need batching is first-level analysis, where timing information is entered for each session (or run) for each subject. Back in the autumn of aught eight during my days as a lab technician I used to be just like you, arriving to work in the morning and easing my falstaffian bulk into my chair before starting my mind-numbing task of copying and pasting onset times into each condition for each run, invariably tiring of it after a few minutes but keeping at it, and maybe completing a few subjects by the end of the day. Not the most exciting or fulfilling work, and I probably screwed a lot of things up without noticing it.

SPM has tried to anticipate problems like this by specifying a Multiple Condition option through their interface, where you supply a .mat file for each session that contains all of the names, onsets, and durations for that session, and everything is automatically filled in for you. Which sounds great, until you realize that creating Matlab files is, like, hard, and then you go back to your old routine. (The manual also says that these .mat files can be generated automatically by presentation software such as COGENT, but I have never met anyone who has ever used COGENT; this is, in all likelihood, a fatcat move by Big Science to get you to buy a piece of software that you don't need.)

What we will be doing, then, is trying to make this as straightforward and simple of a process as possible. However, this assumes that you have your onsets organized in a certain way; and first we will talk about how to create those onsets from your stimulus presentation program. This will allow you much more flexibility, as you can choose what you want to write into a simple text file without having to go through copying and pasting data from the E-Prime DataAid program into Excel for further processing. (I use E-Prime, and will be reviewing that here, but I believe that most presentation programs will allow you to write out data on the fly.)

Within E-Prime, you will need to know exactly when the scanner started, and use this as time zero for your onsets files. I usually do this by having a screen that says "Waiting for scanner..." which only terminates once the scanner sends a trigger pulse through a USB cord hooked up to the presentation laptop. We have a Siemens Trio scanner, which sends a backtick ( ` ); check whether your scanner does the same.

Note that I have an inline script (i.e., an object that contains E-Basic code) right after the WaitScanner slide that contains the following code:

StartTimestamp = CLng(c.GetAttrib("WaitScanner.RTTime")
c.SetAttrib "StartTimestamp", StartTimestamp

if c.GetAttrib("Session") = 1 Then

Open "OnsetTimes_" & c.GetAttrib("Subject") & ".txt" For Output as #1
Close #1

Open "OnsetTimes_" & c.GetAttrib("Subject") & ".txt" For Append As #1
Print #1, "Run", "Event", "Onset", "Dur"
Close #1

end if

Also, in the duration/input tab for the properties of waitscanner, I have the Keyboard accepting ( ` ) as an input, and termination when it receives that backtick. The StartTimestamp will simply record when the scanner first started, and the if/then statement ensures that the file does not get overwritten when the next run is started.

After that, the StartTimestamp variable and the newly create text file can be used to record information after each event, with the specified condition being determined by you. To calculate the timing for each event, all you have to do is grab the onset time of a condition through the c.GetAttrib command, and subtract the StartTimestamp variable from that:

Additional runs will continue to append to the text file, until you have all of the timing information that you need for your subject. This can then be parsed by a script and divided into multiple condition .mat files, which we will discuss tomorrow.