Today we will program part of a masked priming lexical decision task, as reported in Feldman et al. (2009). The key/new tasks you will learn this week are:
As with last week we are going to simplify the design from the paper. To begin with we are only going to include word trials, and only two types of prime trials; semantic primes (i.e. trials where the Target has related meaning to the Prime, and shares several letters), and orthographic primes (i.e. trials where the Target does not share a measning with the prime, but does have an overlap in letters).
The method I discussed in class for removing stimuli during a trial appears to be the method that you are meant to use. There is a page on the Millisecond website that suggests this as the solution if you want to have a stimuli appear for a limited time on a trial, see- How to erase stimuli. I am not sure why they don’t mention it in the context of the examples they give for stimulustimes/frames attributes, as it seems very relevant for the masked priming examples they give.
Like last week we are going to start a new Inquisit file for this weeks exercises. Call this file surname_wpa4.iqx. This is the file you will send me at the end of the class. I strongly recommend that you copy the defaults element from last weeks script into the top of this file, so that you have an easy way to terminate the Experiment.
Furthermore, I recommend keeping your wpa file from last week open, as it may be useful to check code from last week or copy segments.
Many of you didn’t complete WPA 3 last week. Our Experiment this week won’t involve any manipulation of conditions between subjects, so if you didn’t complete last weeks WPA up to (and including) Exercise 4 you will miss out on how to do this. So the first exercise this week is to complete Exercises 3 and 4 of WPA 3, if you haven’t already done so. The extra exercises beyond 4 are merely bonuses so aren’t necessary to complete.
To save you time (and repetition) I’ve created the stimuli for you (they are in the week4.txt file in the dropbox folder ). There are two item elements in the folder, primes and targets. There are also 2 text elements with matching names. Given that last week we had 6 types of trials, and needed 6 item and text elements to match this, why do we only have a sinle item list for both primes and targets, given that there are two types of each? Write down your answer before you check.
Last week we wanted to specify either different responses for our trials types (based on the category), or control when specific trial types were shown (based on the difficulty).
This week we dont need to do either of these. Instead on every trial, regardless of whether it is a semantic or orthographic prime trial we want to collect the same response (i.e. whether it is a word or non-word). We also dont want to control the order of the two trials types, but intermix them instead. So we dont need to refer to the two trial types separately at either the block, experiment or trial level.Now that we hae defined our stimuli, the first step for you is to define how these stimuli will be used on each trial. To begin with, create a trial element called word, and set the valid responses to W for word and N for non-word. You should be able to do this from previous weeks.
<trial word>
/validresponse = ("w", "n")
</trial>Now we need to define what stimuli should be displayed on a word trial and when. This is going to involve setting the stimulustimes attributes, like we have done in previous weeks. What we want is for an item from the primes stimuli to be displayed at the start of the trial for 50ms, then for an item from targets to be displayed from 50ms onwards.
(Hint: On the surface this might seem quite new, but you have actually been using a similar setup everyweek when you tell Inquisit to display the “Get Ready” prompt at the start of a trial.)
<trial word>
/stimulustimes = [0=primes; 50=targets]
/validresponse = ("w", "n")
</trial>
BAD SOLUTIONS
<trial word>
/stimulustimes = [0=primes; 50=clear; 50=targets]
/validresponse = ("w", "n")
</trial>
<text clear>
/items=(" ")
/position = (50%, 50%)
/hjustify = center
/fontstyle=("Arial", 50%)
</text>
Important: When we use this setup, the trial starts as soon as the prime is displayed. However by default Inquisit wont check keyboard inputs (i.e. whether they have pressed W or N), or begin recording response times until the final stimuli is shown (in this case after 50ms when a target is shown). In this case this is exactly what we want Inquisit to do, but there may be times when this is not what you desire. The trial element has attributes that can change this, check out the helpfile if you are interested..This week nothing much is happening at the trial or block level. We just want to present a single block of trials, where every trial is drawn from the same trial set (i.e. word). Create block and trial elements so that every stimuli is shown once in the Experiment.
<block one>
/trials = [1-10=word]
</block>
<expt>
/blocks=[1=one]
</expt>If you want to you can add a reminder of which keys participants should press by using the bgstim attribute.
If you run your Experiment now you should go through 10 trials, with a random prime shown (very briefly) on each trial, followed by a random target. Once the target is shown you can then take as long as you want to press either the W key, to indicate the target is a word, or the N key to indicate it is not a word. This differs from the Experiment described in the paper in two ways; 1) In the paper they had only 3 seconds (3000ms) to respond once the Target is shown, not infinite time. 2) In the paper each prime was paired with a particular target, not randomly paired.
First we will create the 3000ms cut-off for responding. At what level of the Experiment do you think this kind of restriction should be placed (i.e.Stimuli, Trial, Block or Exp)?
This is a constraint that we are placing on what happens during a trial. Therefore the best place to start looking for how to do this is at the trial level. We have spoken before about how you might define elements on the block level that you want to appear on multiple trials (i.e. the correct/errormessage attributes from last week). Nevertheless the first place we will look is at the trial level.To start with have a look at the help file again for the trial element. You’ll see that there is an attribute called timeout. Generally names of attributes in Inquisit are pretty informative, and that holds in this case. The timeout attribute does exactly what the name suggests, and exactly what we want, it times out, or ends, the Experiment after a given interval (expressed in ms, like stimulustimes). Add a timeout attribute to your trial so that it ends after 3000ms. Also add a pretrial pause of 1500ms, to give some space between trials (see last week).
<trial word>
/stimulustimes = [0=primes, 50=targets]
/validresponse = ("w", "n")
/timeout=3000
/pretrialpause=1500
</trial>Try running your code again. If you don’t respond how long does the trial last, from prime to timeout? Change the stimulustime for the targets stimuli to 2000ms. Now how long does it last
The timeout attribute sets how many milliseconds the stimuli should be displayed for after the last stimuli passed to stimulitimes/frames is shown. So if the last stimulus is show 50 ms after the trial starts (e.g. /stimulustimes=[0=primes, 50=targets]), then the timer would start after 50 ms seconds and the trial would run for 3050 ms.
If instead the last stimulus is shown after 2000ms, then the trial will run for in total 5000ms. Keep this in mind when specifying trial timing.What happens, exactly, if you don’t respond?
Wouldn’t it be nice to give the participants a reminder warning to respond faster when thy are slow?
Last week I mentioned a 3rd message attribute /responsemessage. Unlike the previous correctmessage and errormessage we used last week, this message can only be set at the trial level, and takes 3 inputs, namely;1) the response which triggers it (e.g. “W”, “N” etc.), 2) the message/stimulus to display (same as the first variable for correct/errormessage), and 3) the length of time (same as the second variable of correct/errormessage). If you look back at the help file for timeout you will see that there is a particular response variable that Inquisit uses when a participant runs out of time before responding. We can use this to trigger a response message.
For it to work though you’ll need to specify a new text element that contains the warning message.
<trial word>
/stimulustimes = [0=primes, 50=targets]
/validresponse = ("w", "n")
/timeout=3000
/pretrialpause=1500
/responsemessage=(0, noresponse, 500)
</trial>
Make sure you define a test element called noresponse somewhere or it wont work.The final feature we need to implement is a way to tell Inquisit that when it displays item 3 from the primes list, it should follow it with item 3 from the targets list.
A bad way to do this would be to set both the selection method within both the primes and targets text elements to sequence. What happens if you do this? Why is this bad?
What you should see is that each prime is now paired with the correct target (yay), but they always appear in order from target/prime 1 to target/prime 10 (bad). Its very rare that you want to present the stimuli in a non-randomized fashion like this. So this isnt the solution we want to use. The results of Exercise 5a, while not exactly what we want, suggest that our solution may lie in how the text elements select items from their respective item elements. Logically, what we are trying to do is control this selection, as this is the level at which we (often) control the presentation order of stimuli.
In order to Implement a correct solution, I need to introduce a few new concepts.
At this point we have often used the same names for multiple elements of different types (for instance we currently have both and item and text element named primes). This hasn’t been a problem for Inquisit because every time we have needed to call one of these elements, the context in which we have called it has specified for Inquisit which element, text or item, we are referring to.
For instance when we set stimulustimes=[0=primes] Inquisit knows to use the text element primes rather than the item element, because stimulustimes only ever calls Elements at the stimuli level (like text pictures etc.). If we instead had both a picture element called primes, and a text element called primes, then Inquisit wouldn’t know which element you are referring to (as they are both stimuli elements).
Fortunately Inquisit also has a way of specifying which element you want more precisely. Put simply, you separate the element type and element name by a period (.), so elementtype.elementname (e.g. text.targets, item.targets).
Inquisit also stores various variables related the elements which it uses when running an experiment. For instance, if you have looked at the data file from your Experiments you see that each trial it records responses and latency (or the time it took to respond). You can access these variables directly in your Experiment script as well, using the same convention above, but adding the variable name you are interested in. For instance trial.word.latency will give you the response latency for the last time that trial word was run.
One of the variables that inquisit stores for text (and picture etc.) elements is the currentindex. This variable returns the number of the item that the element is most recently calling. So for instance if text.primes had most recently sampled item 3 from item.primes, then text.primes.currentindex would return the value 3. If we then passed text.primes.currentindex to the /select attribute of another text element, then we would essentially be forcing that element to sample item 3 from its associated item list. More usefully each time that second text element needed to select an item, it would check what the currentindex is of primes text.
Now try to implement this in your code. You’ll need to specify a random selection method for one item in the same way as usual, and set the select method for the other item to check its currentindex
<text primes>
/items=primes
/position = (50%, 50%)
/hjustify = center
/fontstyle=("Arial", 4%)
/select=noreplace
</text>
<text targets>
/items=targets
/position = (50%, 50%)
/hjustify = center
/fontstyle=("Arial", 4%)
/select=text.primes.currentindex
</text> One thing we haven’t discussed is how you can give participants instructions before they begin the task. The easiest way is at the block level, where you can set preinstructions and postinstructions. These set instructions to be displayed before the block begins and after. See if you can work out how to use them. You’ll also need to look up pages elements, which you can passs to the pre and post instructions attributes, and also the instruct element. Pages are your instruction pages, and essentially are just your text with no other attributes. Instruct element, is kind of like the defaults element. It sets controls and criteria that will apply to all pages elements, including how to progress through the instructions.
#This sets each instruction page so that to exit the page/progress you need to press the spacebar. It also tells the participant this.
<instruct>
/nextkey = (" ")
/nextlabel = "(Space) Next page..."
/windowsize = (90%, 90%)
</instruct>
#This would create an instruction page which simply says 'Hey here are the instructions for the task. If...'
<page taskinst>
Hey here are the instructions for the task. If you want to create a line break you need to put ^^ at the end of the paragraph.
</page>
#Finally we tell the block that it needs to display this task instruciton page at the beginning
<block one>
/trials = [1-10=word]
/preinstructions = (taskinst)
</block> If you’ve done everything to this point great work. There is still one important feature of the task we haven’t implemented. In the real experiment they masked the stimuli using a sequence of ### that matched the number of characters in the prime. Go through your code and add in this mask, it’ll require changing your trial, as well as creating new stimuli.