Headturn preference paradigm example

About this protocol

The following protocol is based on the Newman (2009) paper cited below. A headturn preference procedure is used to assess whether infants can recognize their own name being spoken when multiple other talkers are speaking in the background.

Newman, R. S. (2009). Infants' listening in multitalker environments: Effect of the number of background talkers. Attention, Perception & Psychophysics, 71, 822-836

This study was run prior to the development of BITTSy on an older, hard-wired system in our lab. However, the following example BITTSy protocol replicates its structure and settings, and has been used in our lab for studies in this same body of work.

In headturn preference procedure, we'll start off with the participant facing a neutral direction, then have the participant turn their head to listen to an audio stimulus. For as long as they are interested in that stimulus, they tend to keep looking toward where the sound is coming from. When they get bored, they tend to look away. Across trials, we can use how long they listen to stimuli as a measure of listening preference.

Infants as young as four months old will listen longer to their own name (a highly familiar word) than other, unfamiliar names. In this study, we'll present names with noise of other people talking in the background. If infants still listen longer to the audio that contains their own name, we can say that they can still discern their name and recognize it as familiar, despite these harder listening conditions. By testing infants' success in this task at different age ranges, with different types of background noise, and at different noise levels, we can better understand infants' speech perception abilities.

This study begins with a phase that familiarizes infants with the procedure, and continues until they accumulate a certain amount of looking time toward the audio stimuli in this phase. In the test phase, we present three blocks of four trials each, with the trial order randomized within each block.

Starting the protocol

Starting definitions

As always, we open with starting definitions. For this headturn preference study, we will use three lights in our testing booth: one directly in front of the participant, and one each on the left and right sides of the testing booth which the participant must turn their head 90 degrees to view. Our lab's starting definitions look like this:

SIDES ARE {CENTER, RIGHT, LEFT}
LIGHTS ARE {LEFT, CENTER, RIGHT}

A note about HPP and defining LEFT and RIGHT

In this headturn preference study, we will be turning on light/speaker pairs that are located on the same side of the testing booth. It will be important to define your LEFTand RIGHTlights in a way that matches up with your left and right speaker channels, so that each light/speaker pair can be turned on and off with the same side name. Here, the lights that we define as LEFTand RIGHTmatch what we see in our booth from the experimenter's perspective, and we have set up our stereo audio system with the left-channel and right-channel speakers directly behind these LEFT and RIGHT lights, respectively.

You can choose to name the sides of your booth according to your experimenter's perspective or your participant's perspective, whenever they don't match - it doesn't matter, as long as the lights and speakers that should be treated as a pair have the same side name, and it's clear to your experimenters how to identify these sides via your key assignments for live-coding.

See the starting definitions page for more on how to order these definitions in a way that fits your own testing setup.

Tags

In this protocol, we have six files to use and assign tag names - two clips of classical music to use in the familiarization phase, and four audio files for the test phase, in which a speaker repeatedly calls a name with the noise of several people talking in the background. One name file is the name the participant is most commonly called ("Bella" in this example), one has a name that matches the stress pattern of the participant's name ("Mason") and two foil names have the same number of syllables but a different stress pattern ("Elise" and "Nicole").

LET trainingmusic1 = "C:\Users\ldev\Desktop\BITTSy\HPPExample\trainingmusic1.wav"
LET trainingmusic2 = "C:\Users\ldev\Desktop\BITTSy\HPPExample\trainingmusic2.wav"
LET ownname = "C:\Users\ldev\Desktop\BITTSy\HPPExample\bella_sm_10dB.wav"
LET matchedfoil = "C:\Users\ldev\Desktop\BITTSy\HPPExample\mason_sm_10dB.wav"
LET unmatchedfoil1 = "C:\Users\ldev\Desktop\BITTSy\HPPExample\elise_sm_10dB.wav"
LET unmatchedfoil2 = "C:\Users\ldev\Desktop\BITTSy\HPPExample\nicole_sm_10dB.wav"

Because the stimuli in this experiment are particular to each participant (one of them must be that participant's name), we make a copy of the protocol before each participant's visit that has the appropriate filenames filled in for their session. Tag names let us label these generically by what trial type it is (name, matched foil, or unmatched foil) rather than the particular name that was being called, and once we change the filenames they reference, no further changes to the protocol are necessary to prepare for each participant's session.

These tag names, which are kept consistent, will also appear in the reports of session data rather than the filenames, allowing us to easily combine data across participants even when stimulus files themselves differ. (And keep reports de-identified, in this study in which their first name is a stimulus!)

Groups

Having defined our tags, now we'll create groups that will help us define our stimulus selection later, in the familiarization and test phases of our experiment.

The training phase is straightforward - we'll just present those two music clips throughout.

LET trainingmusic = {trainingmusic1, trainingmusic2}

But in the test phase, we'll use a block structure. Each of the four trial types will be presented in a random order in each block, and we'll have a total of three blocks. All our test blocks have the same four stimuli. However, we'll define three copies of this group - testblock1 to testblock3 - which will allow us to randomize the order of stimuli within each block completely independently from the other blocks.

LET testblock1 = {ownname, matchedfoil, unmatchedfoil1, unmatchedfoil2}
LET testblock2 = {ownname, matchedfoil, unmatchedfoil1, unmatchedfoil2}
LET testblock3 = {ownname, matchedfoil, unmatchedfoil1, unmatchedfoil2}

You might wonder why we can't define a single testblock group, and just restrict selection from that group to produce the desired block structure. See the last example in the max <number> repeats in <number> trials section for why this doesn't work, and its following section for more on why this nested group structure is a good solution for creating blocks in experiments.

And we need an overarching group for the test phase that contains our blocks:

LET testaudio = {testblock1, testblock2, testblock3}

In addition to randomly ordering stimuli, we will want to randomly order stimulus presentation locations. We can set up for this by creating groups of sides. CENTER in this experiment is used only for in between trials; LEFT and RIGHT are the sides for selection here. We'll place some restrictions on the randomization order (e.g. to prevent too many trials in a row on the same side), but we'll have these restrictions reset between the familiarization phase and test phase. Therefore, we'll make two groups of sides, one to use in each phase, so that when we switch to the test phase, we're starting fresh on which side choices are allowable.

LET trainingsides = {LEFT, RIGHT}
LET testsides = {LEFT, RIGHT}

Optional experiment settings

At this point in the protocol, we would define any optional experimental settings we needed. In a HPP study, relevant ones for consideration are COMPLETELOOK and COMPLETELOOKAWAY as well as key assignments for live coding. Here, we'll use all the defaults, so we won't need to include any - but this is how they would appear.

DEFINE COMPLETELOOK 100
DEFINE COMPLETELOOKAWAY 100
DEFINE ASSIGN LEFT KEY L
DEFINE ASSIGN RIGHT KEY R
DEFINE ASSIGN CENTER KEY C
DEFINE ASSIGN AWAY KEY W

See also our page on live coding for recommendations on key assignments and details on how live coding works in BITTSy.

STEPS for execution

Now we're ready for the body of the protocol - what will happen when we click the button to run the protocol.

Familiarization

First, we'll start off the training phase, in which we simply familiarize the participant to the basic procedure. First, a light will start blinking in the center of the booth, getting the participant to attend to this neutral direction before a trial starts, so that they later will demonstrate a clear headturn to attend to stimuli on the sides of the booth. Once the experimenter judges they are looking at it (by pressing the key assigned to CENTER), it turns off.

STEP 1
Phase Train Start

STEP 2
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 3
LIGHT CENTER OFF

Immediately, one of the side lights will turn on. We choose this side randomly to be either LEFT or RIGHT, but restrict the randomization to not choose the same side more than 3 times in a row. Once the participant turns and looks at this side light, the experimenter will press a key to indicate they are now looking in that direction.

STEP 4
LET side1 = (FROM trainingsides RANDOM {with max 2 repeats in succession})
LIGHT side1 BLINK 250
UNTIL KEY L
UNTIL KEY R

In a protocol that assigned different keys to LEFT and RIGHT, the terminating conditions for this step should be until those keys were pressed, rather than L and R

Now, immediately once the look toward the light is recorded, a trial starts. Audio will begin to play from the speaker directly behind the light. It will continue to play until either the file ends, or the participant looks away for at least 2 seconds - whichever comes first.

STEP 5
Trial Start
LET training_audio = (FROM trainingmusic RANDOM {with max 0 repeats in succession})
AUDIO side1 training_audio ONCE
UNTIL FINISHED
UNTIL SINGLELOOKAWAY training_audio GREATERTHAN 2000

Here, we choose the audio for the training trial from the trainingmusic group such that we cannot pick the same music clip twice in a row. The two clips will play alternately throughout the training phase.

Once one of the step terminating conditions is met, we want the trial to end. The light should turn off, and so should the audio. (If the FINISHED terminating condition was the one that was met, it has already stopped playing, and the OFF command does nothing. But if the SINGLELOOKAWAY one was met instead, it would continue to play if we didn't turn it off now.)

STEP 6
Trial End
LIGHT side1 OFF
AUDIO side1 OFF
UNTIL TIME 100

We end this with UNTIL TIME 100 just to have a tiny perceptible break between turning this side light off, and the start of the next inter-trial period - which we'll get to via a loop.

Up to now, our steps have defined the basic structure of our training phase: start the CENTER light, wait for a look and turn off, start a side light, wait for a look and play a trial. We can now define a loop that will repeat this basic structure until the participant is sufficiently familiarized to proceed to the test phase.

STEP 7
LOOP STEP 2
UNTIL TOTALLOOK trainingmusic1 GREATERTHAN 25000 THIS PHASE and TOTALLOOK trainingmusic2 GREATERTHAN 25000 THIS PHASE

STEP 8
Phase End

We'll loop back to STEP 2 (where we turned on the CENTER light to re-orient the participant between trials), and execute all the steps back to STEP 7, running another trial in the process. We keep looping back over these STEPs until the child accumulates 25 seconds of total looking time to both of the music clips. Once this happens, we consider the participant to be sufficiently familiarized with the study procedure, and end the training phase.

Test

Now, time for the test phase. Recall that we have three test blocks. Each is a group of tags, within the group testaudio that contains all three blocks. The first thing we'll need to do is pick a block.

STEP 9
Phase Test Start

STEP 10
LET block = (TAKE testaudio FIRST)

All the blocks in this experiment contain the same tags, so it doesn't matter whether we choose by FIRST or RANDOM. But we do want to use TAKE rather than FROM. When we later choose the stimuli from within the block for each trial, we're going to use TAKE to remove them so that they aren't chosen on more than one trial within the block. If at the end of the block, this empty block was still available for choosing from testaudio (i.e. if we used FROM) we could get in trouble if we picked it again - we'd try to select stimulus files from the block, but there wouldn't be any more in there to pick, and our protocol would have an execution error and stop running.

The test phase of the protocol will start off the same way that the familiarization phase did - by defining the inter-trial period, with the flashing CENTER light, then choosing which side of the booth the test trial will be presented on. We'll select from testsides this time, and give it the dynamic tag side2 so that we can refer to this side for the light, and later the audio. No two tags, including dynamic tags, can have the same name, which is why we define our placeholder tag for the active side as side1 in training and side2 now.

STEP 11
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 12
LIGHT CENTER OFF

STEP 13
LET side2 = (FROM testsides RANDOM {with max 2 repeats in succession})
LIGHT side2 BLINK 250
UNTIL KEY L
UNTIL KEY R

Now for a test trial. From the block that we chose back in STEP 10, we'll select a random tag to play - either ownname, matchedfoil, or one of the two unmatched foils. We want to select these without replacement using TAKE, so that we never repeat a single stimulus within the same block.

STEP 14
Trial Start
LET trial_audio = (TAKE block RANDOM)
AUDIO side2 trial_audio ONCE
UNTIL FINISHED
UNTIL SINGLELOOKAWAY trial_audio GREATERTHAN 2000

STEP 15
Trial End
AUDIO side2 OFF
LIGHT side2 OFF
UNTIL TIME 100

Now, we'll define a loop that will let us play a trial (with the blinking CENTER light in between) for each trial type in the block. We loop the section 3 times, so that we end with 4 trials total.

STEP 16
LOOP STEP 11
UNTIL 3 TIMES

Note that we loop back to STEP 11. That was after we selected a block from the testaudio group, so the dynamic tag block refers to the same block throughout this whole loop. This is what we want - to TAKE each of the items from the same block and play them in a trial by the time we're done with this loop.

From STEP 10, where we select a block, up to this point constitutes one block out of three in our test phase. This is only a third of our trials - but we're almost done with writing our protocol. Because each block has the same structure, we can make another loop to repeat the process of selecting a block and playing four trials within it - we'll add an outer loop, which will contain the loop we've already defined.

STEP 17
LOOP STEP 10
UNTIL 2 TIMES

When we loop back to STEP 10, we pick the next block out of testaudio, and repeat the whole structure, including the loop at STEP 16 that lets us run through all four trials within the new block we've selected. When this loop in STEP 17 finishes and our second block of trials have played, we loop through again for our third block. Then, when the STEP 17 loop has run 2 times - all three of our test blocks have been completed - our experiment is done.

STEP 18
Phase End

These kinds of loops may not be totally intuitive if you are used to thinking of your experiments as a linear progression of trials. However, loops are well-suited for any kind of experiment that has repeating units with the same internal structure, and they will save you tons of effort in defining your protocols!

See the resources page for a copy of this protocol.