Over the course of building numerous experiments in PST’s E-Prime, I’ve picked up a number of tricks that I find useful. A lot of these are in fact quite basic programming techniques, but ones which seem to me worth documenting because I initially found it non-obvious how to implement them in E-Prime. Partly for my own reference, and partly in the hope that they might be of use to other E-Prime users, I’m planning over the next few weeks to write up and post the tricks I’ve discovered so far, as well as new ones as I discover them. I would of course be very interested to hear if anyone has comments or feedback, or alternative ways of achieving the same effects (or, for that matter, other useful tricks of their own).
So, without further ado…
Trick 1: Context Attributes
In many situations, it can be very useful to be able to set attributes at the top of an application or experiment. By defining a setting at the top (for example, the filename of a sound file that will be played multiple times during the experiment), and then referring to it by its attribute name throughout the experiment, it becomes very straightforward to swap that sound file for another at a later date: rather than having to comb through the experiment looking for everywhere that it might have been referenced, we can simply change the single context attribute “Sound1Filename” to the name of the new file, and every reference to SoundFile1 will be updated in one go. This not only makes it far more straightforward to modify an experiment, but it also greatly reduces the risk of introducing bugs by accidentally missing a reference that needs changing.
It’s possible to do this in E-Prime by using the E-Basic command “c.setAttrib” in an InLine object. I usually call this object ‘Definitions’, and place it at the very top of the experiment, like so:
You can then define attributes inside it as follows:
c.setAttrib "Sound1Filename", "sounds/sound1left.wav"
The above example would assign the value “sounds/sound1left.wav” to the attribute “Sound1Filename”, which can then be referred to anywhere in the experiment – using E-Prime’s square bracket notation – as [Sound1Filename] :
The uses of setting attributes like this are not limited to setting filenames. It’s also possible to dynamically change text in Text objects, set the correct response key globally, etc. By way of example, here are some examples of context attributes one might use in a dichotic listening-type experiment:
c.setAttrib "Attend", "left"
c.setAttrib "Ignore", "right"
c.setAttrib "Sound1FileName", "sounds/sound1left.wav"
c.setAttrib "Sound1CorrectAnswer", "z"
The first two – “Attend” and “Ignore” – simply fill in text in the instructions throughout the experiment. This allows us to very easily create a reverse-stereo version of the experiment, simply by swapping these two around. Since our instruction Text objects are all written in the form “You will be played a sound in the [Attend] ear…”, this allows us to change all the relevant instructions just by changing these two lines.
The third we have already discussed – it sets the filename of the sound that we’re using, making it easy to swap in a different sound at a later date.
The fourth sets the correct response key to this particular sound – this makes it easier to change the response key and, again, it removes the possibility that if we do change it then we’ll overlook one place where this occurs.
There are almost certainly other uses that the above trick could be put to. I think a good principle to follow is that if something is going to be referred to multiple times throughout the experiment, and if there’s a chance that that thing might need to be changed in future, then it’s worth considering setting it as a context attribute by the above technique.
Nick, Nice job, thanks very much for posting this and for bringing this page to our attention on the E-Prime Google Group, I might even add a couple tricks from my “Mastering E-Prime” series. One comment about Trick 1, you might want to change the wording so as not to confuse readers who will later use actual global variables. What you call “global variables” are really “context attributes” — as you will recall from Chapter 4 of the E-Prime User’s Guide, variables and attributes are distinct concepts, and there is a reason that PST uses the term “attribute” instead of “variables”. Users who get used to saying “variable” when they mean “attribute” will find themselves confused later when they have to use actual variables, and we should spare them that.
Regards,
— David McFarlane, Professional Faultfinder
Thanks very much for the feedback, David – I’ve amended the text accordingly (unfortunately I can’t really change the URL now without breaking the link here). Apologies for my misuse of terminology there: I hadn’t actually realised that E-Prime has its own “global variables” in addition to context attributes, so I’ve learnt something useful already!
(I suspect with hindsight that even if “global variable” didn’t already have a meaning in E-Prime, it was still probably not quite the right term: “named constant” might have been better, since this technique was my attempt to implement in E-Prime the named constants that I’m familiar with from the web scripting language PHP… for fear of causing confusion I’ll be more careful to stick to E-Prime’s terminology from now on though!)
I’m definitely no expert in E-Prime – the tricks I’m planning to post here are really all fairly simple things that I had to do a certain amount of digging in order to figure out how to implement, but which I have subsequently found useful or time-saving – so please do continue to correct me if I make (or have already made!) further mistakes, or if you know of a better way of achieving the same effects.
(Oh, and please do feel free to post hyperlinks in comments if you have posted useful tricks elsewhere).
hi,
thanks for the tricks. i was wondering whether you might know of a way to have e-prime automatically print in the output which sound was played (or what image was presented). it would seem like a very useful feature to have, especially when what is programmed in the soundOut properties is not a specific file but a reference to one of multiple columns in a list.
i am using a series of attributes, and conterbalanced and randomized cycles tot determine the appropriate list of sound to play for a given group, and i would really like to be able to verify that, for every subject, what was actually played matched what i am expecting it to play. I tested the program with a miniature version my sound lists and it seemed to work as i expected but it would be really nice to have e-prime output every sound that it actually played.
thanks a lot,
amélie
Hi Amélie, thanks for the comment. I’ve had a look through some experiments I’ve made that sound like they might be similar to yours, and as far as I can see SoundOut objects don’t seem to have an option to log the filenames of files played, but if the filename is specified by an attribute (eg. [SoundFile]), then it will log the filename as the value of that attribute on each cycle. I’d guess that if you’ve specified [SoundFile] as the filename, then it would be safe to assume that what is recorded in the “SoundFile” column for each cycle was what was in fact played during that cycle.
I hope that helps. If not (and if you haven’t already tried them), why not try PST’s forums or the E-Prime Google Group – I’ve found them both to be really useful sources of help when I’ve had similar E-Prime problems that needed solving.
Nick,
Just what I was looking for. Very helpful! When do you plan on posting your next trick?
Zach Barnett