BITTSy (Behavioral Infant & Toddler Testing System) was designed to be a consistent, multi-paradigm infant experimental testing platform that can be easily set up across multiple sites in a uniform manner, establishing a standardized research tool that will enhance cross-site research collaborations. The testing platform can run several key infant testing protocols (Headturn Preference Procedure, Preferential Looking, and Visual Fixation/Habituation) using the same standard design.

Our intent was to create a single program that could run a wide range of infant paradigms in a comparable fashion, that used off-the-shelf equipment, which would make it cost-effective. By creating such a system, we hoped to be able to facilitate growth in our knowledge of early language development across diverse circumstances.

To date, most individual projects on language development have acquired data in a single laboratory. The ability to have a comparable experimental setup across labs will enable researchers across institutions to start to develop collaborative research approaches; this is particularly important for assessing low-incidence linguistic populations (where no single location would be able to recruit sufficient numbers of participants). BITTSy provides improved reliability and consistency across research sites by promoting multi-investigator and multi-site collaborations. Shared resources allow for collaborative testing of low-incidence populations or populations located in different geographical regions, such as comparisons between infants learning different languages.

The lack of an easily-accessible and cost-efficient system also deters new investigators from initiating research programs that rely on some of these testing methods, particularly HPP for which there are no off-the-shelf systems available. While some testing paradigms do have standardized versions available (e.g., Habit runs visual fixation procedures, although it does not run natively on modern operating systems), HPP does not, and HPP is particularly well-suited to testing young infants. Moreover, there is no single program available that runs a wide range of infant paradigms in a comparable fashion; BITTSy will provide the option of using multiple methods within a single test session.

The Behavioral Infant and Toddler Testing System (BITTSy) was developed at the University of Maryland College Park. It is designed to run classic infant and toddler testing paradigms such as headturn preference procedure, preferential looking procedure, visual fixation/habituation procedures, and conditioned headturn procedure, all within a single freely-available program, interfacing with standard off-the-shelf hardware to allow for standardization and consistency across testing sites and research groups.

In the following sections, you will find more information and guidance on using BITTSy for your own research.

The development of BITTSy was funded by NSF BCS1152109, "New Tools for New Questions: A Multi-Site Approach to Studying the Development of Selective Attention".

In the following discussion, we refer to several standard infant paradigms by acronyms:

BITTSy was designed to allow testing using the Headturn Preference Procedure, a paradigm for which there are no other freely-available standardized test systems. Below we discuss the way HPP works, and some of its advantages.

How HPP works

Since the time it was first developed in the early 1980s (Colombo & Bundy, 1981; Fernald, 1985), the HPP has been a cornerstone method for studying early language development, and has been used in several of the most influential studies in infant speech perception (e.g., Fernald, 1985; Jusczyk & Aslin, 1995; Saffran, Aslin, & Newport, 1996, collectively cited more than 1000 times). The last substantial modifications to the method were made in the mid 1990s (Jusczyk & Aslin, 1995; Kemler Nelson et al., 1995) and current set-ups have lagged behind advances in software programming and hardware. In the standard variant, infants sit on their caregivers’ laps in a 3-walled test booth (see Fig. 3). Based on an observer's real-time coding of infant orienting behavior, a computer controls flashing lights, one on each wall of the booth, and 2 audio speakers, one under each of the side lights. Typically, trials begin with the light in front of the infant flashing, attracting the infant’s attention front and center. After the infant orients to the center, the light stops flashing and one of the two side lights begins to flash. When the infant turns towards that light, sounds begin to play from the speaker on that side; sounds continue until the sound file ends or until the infant looks away for a pre-determined amount of time (usually 2 seconds), ending the trial. By comparing infant orientation and attention to trials of different types, researchers can examine the types of sounds and sound patterns infants recognize, differentiate, or prefer. Although some studies have used HPP to test infants’ ability to discriminate between different stimuli (e.g.Nazzi et al., 2000), its most common use is to test either infants’ recognition of stimuli or their preference for specific components of their native language (see Johnson & Zamuner, 2010 for a recent review). When combined with a familiarization or training phase, this paradigm not only examines what children have already learned about their language(s), but also provides information as to what they are able to learn in the laboratory (Marcus et al., 1999; Saffran et al., 1996).

Benefits of the HPP Procedure

• HPP uses infants’ natural tendency to maintain visual orientation towards an attended sound source

  • The task puts minimal demands on the infants as compared to tasks that require children to understand verbal instructions and produce an overt reaching or verbal response.

  • This makes HPP ideal for separating differences in perceptual skills from differences in the comprehension or processing of verbal instructions.

• HPP is easy to use across a wide age-range that includes key milestones of language development.

  • HPP has been used with typically-developing children ranging from 4 months (see, for example, Mandel et al., 1995; Seidl, Cristià, Bernard, & Onishi, 2009) through 2 years (Santelmann & Jusczyk, 1998; Tincoff, 2006), a perfect range for examining early language development.

  • A unique quality of HPP is that it provides opportunities to study developmental change through cross-sectional and longitudinal studies; use of the same task across ages helps to ensure that changes are the result of cognitive/perceptual development rather than differences in task difficulty.

• HPP is extremely flexible.

  • HPP can be used with stimuli ranging in complexity from single syllables (e.g. McMurray & Aslin, 2005) to entire passages (Jusczyk & Aslin, 1995; Soderstrom & Morgan, 2007), and with both speech and nonspeech stimuli.

  • HPP has been used to examine long term memory for sound patterns presented in the lab (Houston & Jusczyk, 2003) and from naturalistic settings (Jusczyk & Hohne, 1997; Saffran, Loman, & Robertson, 2000), and to explore musical knowledge and learning (Krumhansl & Jusczyk, 1990; Saffran & Griepentrog, 2001; Saffran et al., 2000), rule learning (Marcus et al., 1999), auditory stream segregation (Newman, 2005), and knowledge of phonetic categories (McMurray & Aslin, 2005), phonotactics (Chambers, Onishi, & Fisher, 2003, in press; Jusczyk et al., 1993), and prosody (Seidl & Cristià, 2008).

• HPP maximizes research resources, compared to other infant testing procedures.

  • Sessions last approximately 10-15 minutes, which is well-matched to the attention spans of infants in the target age range. Shorter sessions maximize the number of infants who are able to complete the experimental session and provide usable data. Low attrition rate is particularly important when testing populations for whom recruitment can be difficult and costly, such as bilingual or atypical infants.

  • Observer training can be effectively accomplished in a relatively short period of time, thus maximizing research assistants’ time for collecting and analyzing data.

Opportunities for Growth with the Use of HPP

The original use of the HPP paradigm focused on typically-developing monolingual infants in the 4-12 month age range, and there are still relatively few speech perception studies with bilingual infants using HPP (e.g., Bosch & Sebastián-Gallés, 2001; Bosch & Sebastián-Gallés, 2003; Vihman et al., 2007). Although most research using HPP focuses on infants under one year of age, recent work has demonstrated the use of HPP in typically-developing infants in the 20-24-month age range and in clinical populations with children as old as 48 months (c.f., Soderstrom & Morgan, 2007; Van Heugten & Johnson, 2010). Research has also demonstrated links between early listening preferences shown through HPP and subsequent linguistic and cognitive development (Newman, Bernstein Ratner, Jusczyk, Jusczyk, & Dow, 2006). Researchers are also starting to use behavioral paradigms in concert with physiological measures, such as heart-rate and ERPs (Kooijman, Johnson, & Cutler, 2008; Panneton & Richards, under review), and have begun developing visual variants of HPP for testing American Sign Language (Baird, Seal, & DePaolis, 2010). All of these point to new ways to use this paradigm with other populations.

One limitation of previous research with HPP is that the majority of this research has used flashing lights as the primary attention-getting device, and flashing lights may not hold the attention of more cognitively-advanced participants, such as older children. Recent studies have begun showing images on flat screen monitors (Bosch & Sebastián-Gallés, 2001; Volkova, Trehub, & Schellenberg, 2006), an extension that lends itself well to testing older children in that it creates a more visually stimulating environment. BITTSy is designed to allow either the use of traditional lights, or the use of video monitors; if your test room is set up with both, you can switch between them just by what you list in your protocol file (that is, you do not need to set up your system to do one or the other; it can be set up to allow both.)

Limitations of Previous Versions of HPP

Until BITTSy was developed, there was no easily available, off-the-shelf testing system for HPP. HPP was dependent upon custom-designed hardware – the computer needed to be physically connected to the test booth as well as to an input panel which researchers use to indicate the direction in which infants orient. The input panel required specialized wiring, and response boxes needed to be created specifically for each research lab. Most researchers using HPP had to employ their own programmer and electrical engineering consultants to build the system. This limited the use of the approach to only individuals with substantial funding and technical resources and more importantly, it reduced the likelihood of new investigators implementing this methodology.

Since most researchers developed their own systems, there was no standardization, making cross-site collaborative research very difficult. This in turn limited comparative work across populations located in distinct geographical areas (e.g., work comparing infants with different language exposure). This was particularly problematic for research examining the role of different language combinations in infants raised bilingually, in that few locales have easy access to sufficiently large populations of infants raised in particular types of households.

Finally, at the time that BITTSy was created, many of the systems in use were becoming obsolete, as the timing boards and software tied to specific operating systems.

In addition to HPP, BITTSy also allows testing using the Preferential Looking Paradigm (Golinkoff, Ma, Song, & Hirsh-Pasek, 2013). During this procedure, children are presented with pairs of images (or animated objects) on a screen. This can include familiar (e.g., a hand) or unfamiliar items (e.g., an object that the child would not know the label for). Sometimes the objects are presented one at a time (e.g., during familiarization and training), and sometimes they appear in pairs or in groups of 4 images. Images are accompanied by speech stimuli, which may include sentences either teaching children a new word, or instructing them to look at one of the objects on the screen. A digital camera positioned near the screen (typically above or below) records children’s eye movements. Videos of the test-sessions are then coded off-line on a frame-by-frame basis by trained research assistants, to measure participants' fixations and to calculate accuracy and reaction times across trials.

Visual fixation is a type of habituation paradigm frequently used to study either infant auditory or visual discrimination. The Switch paradigm (Stager & Werker, 1997) is one type of visual fixation procedure.

In visual fixation, the infant is facing a central video screen which shows an image on each trial; at the same time, a sound is played. The infant's interest in the auditory stimulus is measured by how long they choose to look at the co-occuring visual image.

In most cases, the image is not intended to represent the sound; for example, the child might see a bullseye image, or a checkerboard, paired with a repeating sound (such as a syllable). At first, the image and sound are novel, so the infant attends for a fair amount of time. But as the trial repeats over and over, the combination of sound plus image eventually become less interesting, and the child's attention level drops. This is referred to as habituation; it is usually defined experimentally in terms of a set decrease in attention (e.g., looking 50% of the time as at the start of the study).

The Switch paradigm is a form of VFP in which infants are first "taught" one or two new words and then tested on their learning of that pairing. During the habituation phase, they are presented with a particular combination of auditory word and visual image. After habituation, the child is then presented with either the same pairing, or a "switch". For example, if the child was habituated with object A + sound 1 and object B + sound 2, they would be tested with either a correct pairing (object A + sound 1) or a switch (ojbect B + sound 1). If children have learned the specific pairing, they should dishabituate (or increase their looking) to the novel pairing.

BITTSy can run conditioned headturn studies, a paradigm in which the child is trained (or conditioned) to turn a particular direction when they hear a particular event or a change in an event. Conditioned headturn can be used to test children's hearing (for audiometry - turn when a sound is heard), or can be used to test discrimination (turn when a change in a repeated sequence of sounds occurs). For the original use of this paradigm, see Eilers, Wilson & Moore, 1977; or see Kuhl , 1985 or Polka, Jusczyk & Rvachew, 1995, for methodological reviews.

In conditioned headturn studies, the child is seated on their parent's lap facing an assistant; the assistant maintains the infant's attention forward by playing silently with toys. Test trials consist of an auditory stimulus - either the presence of a sound, or a change in a background sound.

During training, the test trials are especially salient or obvious (a large change, or a loud sound). Immediately afterwards, a reinforcer then turns on to the side of the infant - originally, this was a lit-up animatronic toy, but it can be anything that would reward (and encourage) a child to look to that side. This reward plays briefly, and then turns off, so that the infant's gaze returns to the assistant, and the process repeats.

After a series of trials, the infant learns to expect that the reward will occur whenever the sound change happens. At this point, the reward itself is gradually delayed relative to the event, such that the infant begins to turn BEFORE the reward happens, or to anticipate it. This is the response that the experimenter is looking for - a turn towards the reinforcer when the particular sound occurs (before the reinforcer), rather than a turn in response to the reinforcer. There is a preset criterion for the test phase to end (e.g., three correct anticipatory head turns).

At this point, training ends, and the test phase begins; the experimenter indicates when a child is ready, and the computer randomly selects either a change trial (where the sound changes) or a control (no-change) trial, where the sound does not change. The experimenter indicates when the child turns his or her head; this leads to 4 potential trial results: a hit (the sound did change, and the infant turned appropriately), a miss (the sound changed but the infant did not turn), a false positive (the child turned even though there was no sound change), or a correct rejection (there was no change, and the child did not turn). These are then used to determine a child's discrimination ability. Only hits are reinforced during this test phase.

An alternative form of conditioned headturn uses two distinct reinforcers, and the infant is trained to turn either to the left or to the right. Other studies add a generalization phase after the standard test phase.

Some studies may have fixed numbers of trials and lengths of trials; these can run somewhat automatically. But for studies in which trial lengths, or the number of trials, depends on the child's looking behavior, there has to be a method for coding that behavior during the course of the study itself.

One limitation of BITTSy is that coding is based on a system of Left / Right / Center / Away coding. If you wish to use a simpler Towards / Away coding, you can essentially use the Center coding as "towards" - but this will still require two keys for the coding system, rather than a single key with a press down /lift up option.

If you do not explicitly assign keys for coding, BITTSy will use the default keys:

C = center L = left R = right W = away

Note, though, that for a standard QWERTY keyboard, this puts the key referring to the left on the right side of the keyboard, and the key referring to the right on the left side of the keyboard, which many coders find very unintuitive. You may find it much easier to select a key under the left hand for left looks, and one under the right hand for right looks. Also, note that this is from the viewpoint of the coder - a look to the left from the coder's perspective (facing the child) is a look to the right side of the test space.

ASSIGN <side> KEY <the key you’d like to use>

Operating system: Windows 10

BITTSy is designed to run on Windows 10. Original development started in Windows 8, but later switched to Windows 10; testing in Windows 8 has ceased, and Windows 10 is our only recommended version. No versions of Windows prior to Windows 8 have been tested. Regular Windows updates should not affect the functionality of the BITTSy application.

Sample computer specs

BITTSy itself does not require specifications beyond a basic desktop computer. However, depending on needs and preferences for particular studies and research programs, you may decide to use BITTSy on a more powerful system, or upgrade particular components to meet certain specifications. If you are in a position to purchase a PC for running BITTSy studies, here are some questions you may wish to consider.

Memory, processing, and graphics processing power

These specs will mainly come into play for loading and rendering video stimuli from your file system and ensuring BITTSy runs smoothly while your operating system runs other processes in the background. Nothing particularly high-end is needed here, but you may want to opt for something mid-range as insurance that there will be no noticeable blips in execution.

Keyboard

The accuracy of keypress timing for live coding depends partially on the quality of your keyboard. Using a bottom-tier keyboard (such as the basic keyboards that are included with a computer purchase) can result in a small additional delay in BITTSy receiving and logging that input has occurred. Many keyboards designed for gaming will list their key response times, but there are diminishing returns from more expensive models; testing various models at UMD has suggested that mid-tier keyboards work fine for live coding purposes.

Display outputs

BITTSy is capable of displaying stimuli across multiple screens (computer monitors, TV displays, or a combination of both). If you are interested in using BITTSy for studies that utilize visual stimuli, ensure that your system can support the number of monitors you would like to use (plus one, for the experimenter's control monitor). Many basic computers will support a dual-monitor setup (suitable for a standard visual fixation or preferential looking procedure), but adding more screens may require a more advanced graphics card and graphics processing power. (More specifically, if you wish to run HPP using side monitors as attention getters rather than using lights, you would need 4 monitors: 3 in the booth and one in front of the experimenter. So your graphics card would need to have places for 4 monitors to plug in.)

Audio outputs

In addition to standard stereo audio (2.1), BITTSy supports multichannel audio, such as 5.1 and 7.1 surround sound. If you wish to make use of audio outputs beyond a two-channel system, check that your computer has (or can be upgraded to) a surround-sound capable card.

Infant testing procedures typically either have sound from front and center (as in PLP), or from the two sides of the room (as in HPP). Sound in HPP is usually played either in stereo from both speakers simultaneously (as in Saffran et al., 1996), or is played only from the same side of the room as the attention-getter. Dichotic presentation is relatively rare, but there are situations in which it would be advantageous to be able to play different sounds from multiple locations at once, such as in studies exploring infant perception of speech in the presence of background noise or studies of speech perception in deaf children with CIs, where little is known about their use of binaural cues.

BITTSy software allows the researcher to output sound individually over any of the speakers available to their system, as well as output sound in stereo (simultaneous presentation of a single file through the left and right channels).

In a standard stereo audio (2.1) system, there is a left channel and a right channel, allowing for up to two speakers. With a surround sound capable system (5.1 or 7.1), you can control more speakers individually (5 or 7 locations, respectively).

Any speakers that are compatible with your computer will work for BITTSy.

• Ensure that your selected speakers will play audio with satisfactory quality and volume for your studies (or additionally purchase an amplifier for the latter).

• Ensure that you have purchased the correct cables to connect the audio output jacks on your computer to your speaker input jacks.

Why not use internal speakers on television displays?

This section is just for those curious about why we recommend a separate speaker system.

Some labs (including ours) may select audio-capable TVs as their displays for use with BITTSy. There are a number of reasons to prefer separate speakers over internal speakers on TVs when running BITTSy studies. Here are the main reasons why we recommend this:

• BITTSy has not been tested with presenting audio over an HDMI audio signal (the main reason - which stems from several of these others!)

• Computers with HDMI outputs have separate sound drivers listed for HDMI and for devices plugged into audio-only ports, which may have different default settings that could complicate setting up or standardizing how audio is presented to different locations in BITTSy.

• Graphics cards with multiple HDMI output ports are more expensive than cards with more non-audio-carrying port types such as VGA and DisplayPort - and computers that can be equipped with these cards are correspondingly more expensive.

• Modern TVs often accept only HDMI input, do not have an option of supplying audio from an audio jack on the computer instead, and output two-channel audio from the left and right side of the device. For left-side and right-side screens that you wish to associate with only left- or right-channel audio (i.e. for HPP studies), this combination makes it impossible to separate channels and present them from the appropriate side. (E.g., a command from BITTSy to play audio on the left would be carried over HDMI to both TV speakers, and both would play audio on the left-hand side of the device - rather than the intended effect of audio being played from only the device that is on the left side of the room.)

• Internal speakers on TVs are generally of poorer quality, and present audio signals with less fidelity, than what can be obtained with external speakers.

We wanted BITTSy to do HPP with off-the-shelf materials. This required finding a solution for blinking lights that did NOT require hard-wiring.

Our solution was a DMX512 lighting system. DMX stands for Digital Multiplex - DMX512 (Digital Multiplex with 512 pieces of information) is basically a standard for digital communication networks that are used to control things like stage lighting (where it initially began), light dimmers, Christmas lights, special effects devices, electronic billboards - basically anything you would want a computer system to control.

To use a DMX system with BITTSy, you need to purchase two pieces of hardware, plus connector cables.

USB-DMX interface

The first piece you must buy is a USB-DMX interface box. Basically, this is what allows you to make the connection between the PC computer and the actual lighting system itself. It takes information from the computer, and then outputs DMX codes.

One end of this has a USB 2.0 port, which connects to your computer (this cable is included when you purchase the device). The other end has XLR ports to connect with the lightbox. There is a port for both DMX IN and DMX OUT, of which you will only need DMX OUT.

DMX Dimmer/Switch Pack

The second piece of hardware you need to buy takes the DMX commands from the USB interface box and uses that to turn things on and off.

This unit has been discontinued, but is still available at many vendors (check out B&H Photo, or search on Amazon, Google or Ebay - there are a LOT of them available), along with a very similar model, the Elation DP-415R.

Dimmer packs take a DMX signal and use it to control power given to outlets along a certain number of channels. The number of channels corresponds to the number of devices you can independently control. There are devices for big light shows and concerts that have many channels and outlets, but basic units like the DP415 generally have four channels. This is enough to allow for left, right, and center lights in HPP that can all turn on and off individually (plus an extra, unused channel).

The DP415 has 8 outlets, in pairs divided between 4 channels. The outlets are 3-prong Edison sockets - the basic outlets you have in your house that take 3-prong connectors -- assuming you are in North America. (Outlets in Europe and Asia are different; you can still use this device, but would need to purchase lights with American-style plugs, or use converters.)

Lights

With this system, the computer can turn on and off anything plugged into the outlets on your dimmer pack. So you can select any type of light you wish, plug them into those outlets, and BITTSy can turn them on/off and make them flash.

Things to consider when selecting lights:

• Cord Length: The DMX system is going to be located near the computer running BITTSy - so you need to make sure you have long enough cords on your lights to reach from there to where you want the lights to be. (You can use extension cords, but if you are worried about timing, at least make sure they are good ones, and are similar in length on the two sides of your testing space)

• Brightness: This is relative to the room space itself, and how dim it is - you want something that is bright enough to be easily seen, but not overpowering.

We then found a cover to go over the lights.

Suitable covers will depend on your lights, room, and intended uses. Some considerations are:

1. Size of the light bulb

2. Brightness of the room during testing, and brightness of the light as it shines through the cover. You want the brightness of the light when it is flashing to noticeably illuminate the participant's face so that your experimenters can see which side is currently active, even if the light itself is beyond the frame of your camera view - but you also don't want the lights to be so bright that they are uncomfortable to look at directly.

Our covers are turn signal/brake light covers designed for a small vehicle, but you can select anything that works well in your room! You could take apart nightlights for their covers, use caps from large Christmas lights, or get more creative with any kind of semi-transparent plastic material - perhaps some hard plastic cups or shot glasses.

You may not need a cover for your lights, as long as they are shining through small openings, with nothing visible behind, and the brightness is okay!

There is also no need for the lights to project past the surface of the booth walls. You could mount the light slightly behind the wall, and line the cut-out in the wall with a piece of colored plastic vellum for the light to shine through. Just be sure that this is still bright enough!

XLR cable

You will need an XLR cable to connect your USB interface box to your dimmer pack. XLR cables can be purchased online or from any A/V store, as XLR is a standard cable format. XLRs used for this purpose are sometimes labelled DMX Turnaround Cables. However, there are many XLR cables with different pin numbers and configurations available - you will need to verify what kind you need.

If you have selected the models described above for your USB interface box and dimmer pack, you need a 5-pin XLR (male) to 3-pin XLR (female) cable (pictured below).

If you have purchased a different USB interface box or dimmer pack than the models described above, connecting your selections may require a different XLR cable type. The cable will need to connect your DMX OUT port on the USB interface box and your DMX IN port on the dimmer pack - check what type of connection these require.

Audio and displays

Follow installation instructions for your selected speakers and displays.

Lights

3. Connect the USB-DMX box to the dimmer pack. The connection between them should be DMX OUT on the USB-DMX box to DMX IN on the dimmer pack. The outputs of the dimmer pack are only for the lights.

5. If you have the DP-415 unit, be sure that notches 1 & 10 are flicked to the “ON” position (toward the top). Notch 1 sets the starting DMX address to the lowest (the options 2-9 are unneeded), and notch 10 makes it function as a switch pack.

After everything has been successfully installed, this is what the booth looks like:

Download BITTSy

BITTSy does not require any installation. Simply unzip your downloaded file and move the folder out of your Downloads folder to somewhere it won't be accidentally erased. Navigate through the subfolders to the .exe file (with the BITTSy spider icon) and right-click to create a shortcut. You can then move that shortcut to the desktop.

Windows Defender or other anti-virus programs on your computer may prevent you from simply double-clicking to open the BITTSy executable from your shortcut. You can right-click and select Open.

If you see a screen like the one below, click "More Info" where it appears below Unknown Publisher, then the "Run anyway" option will appear at the bottom. Once you click this to open BITTSy, Windows Defender will allow you to open BITTSy normally in the future by double-clicking the shortcut.

When you open BITTSy, it will look like this.

The first protocol file you will load and run will be the setup protocol. See below!

Running the setup protocol

This protocol should be run whenever you are setting up a new system with BITTSy, as well as any time that you unplug/replug displays or lights from your system, to ensure that the device ID numbers assigned by your operating system have not swapped around.

The setup protocol is copied below.

# Each protocol begins with definitions of SIDES, DISPLAYS, and LIGHTS. 
# SIDES is an unordered list of labels to be used within the protocol 
# file for different sides. DISPLAYS and LIGHTS should use these same 
# side labels, but should be ordered based on their ID (0,1,2) in the 
# computer system (determined by where they are plugged in). Run this 
# protocol to determine how to order the DISPLAYS and LIGHTS lists for 
# your system. Once determined, the same definition heading can be used 
# for each protocol you run.

# An example of these definitions:
# SIDES ARE {CENTER, RIGHT, LEFT}
# DISPLAYS ARE {CENTER, RIGHT, LEFT}
# LIGHTS ARE {LEFT, CENTER, RIGHT}

# These are the definitions that should be used to run this protocol 
# file and correctly identify ID numbers. Replace the corresponding 
# lines in the protocol below if they differ from these.

# This protocol will first present images giving a 0, 1, and 2 label to 
# the first three monitor IDs in your system. Write down the sides each 
# monitor is for, in increasing number order - e.g. if you see 0 in the 
# center, 1 on the left, and 2 on the right, write down {CENTER, LEFT, 
# RIGHT}. This is the order that you should use for the DISPLAYS 
# definition in each protocol you run.

# Next, the protocol will turn on the lights with IDs 0-2, one at a 
# time. As each light turns on, write down the side it is on. For 
# example, if the left light turns on first, then center, then right, 
# the order you should use in your LIGHTS definitions is {LEFT, CENTER, 
# RIGHT}.

# This set-up protocol must be run again any time monitors or lights 
# are unplugged and re-plugged from your computer system.

# If you have more than three monitors in your system and the desired 
# displays do not have images displayed during this test, note where 
# the monitors that DO have images displayed are plugged into your 
# computer. Power off your computer, switch the plugs of the monitors 
# that you'd like to switch, reboot and rerun this protocol.

# Press the X key to continue after each step.

SIDES ARE {CENTER, RIGHT, LEFT}
DISPLAYS ARE {CENTER, RIGHT, LEFT}	# if using only one monitor, change this line to: DISPLAYS ARE {CENTER}
LIGHTS ARE {LEFT, CENTER, RIGHT}

# replace the following file paths according to where your BITTSy files
# are saved

LET disp0 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\0.png"
LET disp1 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\1.png"
LET disp2 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\2.png"
LET light0 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\light0.png"
LET light1 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\light1.png"
LET light2 = "C:\Users\waz\Desktop\BITTSy_build_7-3\setup\light2.png"

STEP 1
IMAGE CENTER disp0
IMAGE RIGHT disp1	# remove this line if using only 1 monitor
IMAGE LEFT disp2	# remove this line if using only 1 monitor
UNTIL KEY X

STEP 2
IMAGE CENTER OFF
IMAGE RIGHT OFF		# remove this line if using only 1 monitor
IMAGE LEFT OFF		# remove this line if using only 1 monitor

STEP 3
IMAGE CENTER light0
LIGHT LEFT ON
UNTIL KEY X

STEP 2
LIGHT LEFT OFF
IMAGE CENTER OFF

STEP 3
IMAGE CENTER light1
LIGHT CENTER ON
UNTIL KEY X

STEP 4
IMAGE CENTER OFF
LIGHT CENTER OFF

STEP 5
IMAGE CENTER light2
LIGHT RIGHT ON
UNTIL KEY X

STEP 6
LIGHT RIGHT OFF
IMAGE CENTER OFF

Visual stimuli

Stimuli can be flashing lights with appropriate hardware; if so, any lights that plug into standard power outlets are usable. (See section on lights for hardware requirements.)

For stimuli presented over monitors, BITTSy relies on Microsoft Visual Studio; as such, BITTSy should (in theory) be able to handle any kind of media file that can be opened in default Windows programs such as Windows Media Player, since BITTSy is working with exactly the same system interfacing. It may be possible to download codecs to allow for additional formats, but we would recommend using the following:

Video formats: .wmv & .mp4

Image formats: .jpg, .png & .gif

Audio stimuli

Sound output can either be in the form of audio files, or the sound portion of a video file in cases where synchronicity between video and audio is required. For audio files, we recommend the following:

Audio formats: .wav & .mp3

Audio can be encoded at the sample rate and bit depth of your choosing, as long as they are supported by your computer's sound driver. BITTSy does not require any particular settings, and does not downsample files.

All infant testing procedures have some means of attracting the infants' attention, usually via a visual attention getter.

One difference among methods is whether the visual stimuli are (1) flashing lights (as in classic HPP), (2) videos, or (3) static images presented on monitors, as used in PLP or VFP. BITTSy allows the use of either computer monitors or lights to present visual stimuli.

A second difference among methods is whether all the visual stimuli are in front of the infant, common in PLP, or whether there are also stimuli presented on the sides, as in HPP. BITTSy can control the use of 3 different presentation monitors: one in front, and two on the sides of a test room (plus the monitor for the Experimenter). The monitors can be different sizes. For greatest flexibility, we would recommend a large central monitor (which can be used for PLP and VFP, as well as for the central attention getter for HPP with monitors), and two smaller monitors on the left and right sides of the room (for HPP with monitors). You can also have lights in all three locations.

Thus, BITTSy software allows the researcher to select:

• flashing lights or monitors for each stimulus location

• 1 to 3 stimulus presentation locations (for front only, either or both side locations only, or front and side presentation)

See sections below for more information on these two types of visual stimulus presentation in BITTSy.

Tags are keywords defined within your protocol that allow you to refer to:

1. particular files on your computer

2. groups of stimulus files

3. the result of a random selection from a group

Once defined, all three of these types of tags can be used similarly in protocol files. Tags provide a layer of abstraction that allows protocol files to group, select, and reference stimuli (audio, image, and video files on your computer) in dynamic and flexible ways.

Valid tag names...

• must be unique (the same tag name cannot be defined as two separate files/groups)

• must be single "words" that consist of letters, numbers, and underscores (no spaces, and no other symbols)

For more information on the data obtainable from sessions run with BITTSy, see other pages in the Data Output section of the navigation pane.

BITTSy allows images or videos to be displayed to 1-3 screens. In addition, one screen is reserved as the experimenter's control monitor.

We recommend a having a larger central monitor for use in preferential looking paradigm studies/visual fixation studies. Any television screen is fine. Just pick one of the size and quality you want.

Take note of the display output port types from your computer, and the input ports for your displays, and purchase connector cables or converters as necessary. Side monitors will require much longer input cables/extensions.

Protocol files in BITTSy allow you to define what, when, and how stimuli should be presented, setting up the entire structure of an experiment.

The following sections will detail how to set up the basic structure of a protocol file.

Starting definitions are the very first lines of any protocol file. These definitions handle how you, the user, will identify sides later in the protocol, and how BITTSy will map those side names to devices that are plugged into your computer.

Starting definitions can look like this:

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

Or, if your protocol does not utilize all the component types that BITTSy can use, you may only need a subset of these definitions:

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

SIDES

The SIDES definition lists the names that will be used to identify sides in the protocol. In the example above, they are CENTER, LEFT, and RIGHT - but they could be named however you like. They can be listed in any order, but the number of them should correspond to how many distinct sides you will need to refer to later in the protocol.

Once you have decided on your side names and listed them in SIDES, you will use the same ones in the other starting definitions and in action statements throughout your protocol.

The SIDES opening definition is required for any protocol using any type of stimulus presentation: all stimulus types (lights, audio, image/video) require specifying which sides they should be presented on.

DISPLAYS and LIGHTS

Once available side names are given in SIDES, the next thing to set up is how BITTSy will map these names to particular components controlled by your computer, in order to control stimulus presentation across those devices.

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

AUDIO

By default, BITTSy assumes the system is set up for stereo audio (2.1), and allows for control of two channels (LEFT and RIGHT) that can be played from individually or simultaneously (with the command CENTER or STEREO). If your computer is equipped with two or one speakers, this is the correct setting for you, and you will not need to include an AUDIO definition.

If your computer has more than two audio channels, you can include an AUDIO definition to say how you will identify each speaker. For example:

AUDIO ARE {LEFT, RIGHT, CENTER, LEFTBACK, RIGHTBACK}

Like lights and displays, the order in which the sides are listed in the AUDIO definition should match the order in which the peripheral components (speakers, in this case) are numbered by the computer. That is, the speaker with the lowest ID number is given the first listed side name, the second ID gets the second name, etc. Unlike for the lights and displays, the ordering of audio channel IDs is standardized and predictable. Surround sound-capable sound cards have a standard color-coding system to denote which jacks are for which channel(s), and will be listed in order in your manual. Generally, for a 5.1 system, it will match the example above, and for a 7.1 system, the additional middle channels will have the highest IDs and be defined at the end.

Key assignments

If you do not explicitly assign keys for coding, BITTSy will use the following default keys:

C = CENTER L = LEFT R = RIGHT W = AWAY

Key assignments can be changed with the following command:

ASSIGN <side> KEY <key>

Below are several examples.

ASSIGN CENTER KEY UP
ASSIGN LEFT KEY LEFT
ASSIGN AWAY KEY M

Minimum look lengths

COMPLETELOOK and COMPLETELOOKAWAY define the minimum length that a look should be in order to be counted in live coding - that is, the threshold below which any look is considered to be a mistake (as in an accidental double-press of a key, or pressing a wrong key and immediately correcting). Looks below this threshold will have their time folded into the length of a look (in a valid direction) that follows them.

DEFINE COMPLETELOOK <time in milliseconds>
DEFINE COMPLETELOOKAWAY <time in milliseconds>

For example,

DEFINE COMPLETELOOK 250

By default, these times are each 100 milliseconds. The COMPLETELOOK and COMPLETELOOKAWAY settings allow you to change these thresholds up or down, depending on what is appropriate for your study.

These values must be nonzero, but can be set effectively low enough that they will not ever discount any looks (there is a limit on how quickly two keys on the keyboard can be pressed!) However, note that the COMPLETELOOKAWAY value also determines how often time spent looking away is written to the detailed log file during a run. If you are setting this value very low, test your protocol to ensure that the frequent logging is not resulting in any undue load on your computer.

Background color

For any protocol using external displays, at the start of the run, BITTSy will cover them with a solid color background to show whenever they are not actively displaying an image or video. The background color can also show around the edges of images/videos if they do not take up the whole screen, and prevents the desktop from showing if there are any brief gaps between stimuli being displayed.

By default, the background color is black. It can be changed to white by adding the following line to your protocol, anywhere before the beginning of the first STEP.

BACKGROUND WHITE

Habituation-specific settings

LET <tag> = {<tag1>, <tag2>, <tag3>, ... <tagN>}

Tags within a group should be separated by a comma and a space, and there should be no spaces between the opening curly brace and first tag name or the last tag name and the closing curly brace.

Groups refer to tags that have been previously defined, and create a hierarchical structure.

LET dog = "C:\BITTSy-Stimuli\animals\dog.png"
LET cat = "C:\BITTSy-Stimuli\animals\cat.png"
LET snake = "C:\BITTSy-Stimuli\animals\snake.png"
LET turtle = "C:\BITTSy-Stimuli\animals\turtle.png"

LET mammals = {dog, cat}
LET reptiles = {snake, turtle}

LET animals = {mammals, reptiles}

Below is a visualization of the relationships of tags in the above example.

LET has_legs = {dog, cat, turtle}

But we would NOT use:

LET has_legs = {mammals, turtle}

because if mammals is selected first from the group, there is another layer of selection required before finally presenting the stimulus than if we selected turtle initially. BITTSy cannot proceed through different numbers of selection steps based on what is chosen.

In cases where you really want something more like {mammals, turtle}, you can use "dummy groups," which contain only one item, to get around this issue.

LET dog = "C:\BITTSy-Stimuli\animals\dog.png"
LET cat = "C:\BITTSy-Stimuli\animals\cat.png"
LET snake = "C:\BITTSy-Stimuli\animals\snake.png"
LET turtle = "C:\BITTSy-Stimuli\animals\turtle.png"

LET mammals = {dog, cat}
LET testudines = {turtle}

LET has_legs = {mammals, testudines}

Groups of SIDES

There is one special type of group that doesn't contain tags as its elements - it contains side names. This allows for random selection not just of stimulus files (like other groups), but also of presentation location.

LET <tag> = {<side1>, <side2>, ... <sideN>}

LET stim_locations = {LEFT, CENTER, RIGHT}
LET targetsides = {LEFT, RIGHT}

The tag types discussed thus far must be set up in the opening definitions section of your protocol, before the execution of the first STEP, and once they are defined, what they refer to cannot be changed. Dynamic tags are tags that can be defined later in your protocol and used to refer to the result of a selection statement when a tag is chosen from a group. They don't have a fixed identity as "meaning" any other particular tag; rather, they work as a placeholder tag that can still be reassigned to a new item later on in the execution of the protocol.

Steps

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

LET passage1 = "C:\BITTSy-Stimuli\passage1.wav"
LET passage2 = "C:\BITTSy-Stimuli\passage2.wav"

STEP 1
Phase Test Start

STEP 2
LIGHT CENTER BLINK 200
UNTIL KEY C

STEP 3
LIGHT CENTER OFF
LIGHT LEFT BLINK 200
UNTIL KEY L

STEP 4
Trial Start
AUDIO LEFT passage1 ONCE
UNTIL SINGLELOOKAWAY passage1 GREATERTHAN 2000
UNTIL FINISHED

Note that everything in the example above happens within a STEP. These STEPs provide important reference points in your protocol, and all statements should be placed inside the structure of STEPs.

Protocols can be split into as many STEPs as needed or desired.

Phases and Trials

While STEPs provide internal structure to your protocol and are essential to BITTSy's execution of it, phases and trials are optional divisions within your protocol, whose chief importance is for marking sections that you wish to analyze.

Trials

Trials are the basic unit of your experiment that you wish to analyze, and can span across multiple STEPs.

Trial Start

Trial End

Trials are not explicitly numbered or named within the protocol - you merely specify where one should start and where it should end. All trials should have a start and end, and trials should not overlap with other trials.

The below example is what a trial could look like in a standard PLP study.

STEP 1
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 2
VIDEO CENTER OFF

STEP 3
Trial Start
VIDEO CENTER cat_dog ONCE
UNTIL FINISHED

STEP 5
Trial End

Note that the video being presented as an attention-getter is not included within a trial, because we don't have any intention of analyzing this section. Rather, the trial starts immediately before the first stimulus video, and ends immediately afterward.

Phases

Phases can contain multiple trials, and mark divisions between groups of trials or STEPs that should be analyzed completely separately from each other, because they reflect some difference in the task the participant is doing (as in training and test phases; or pre-test, habituation, test and post-test).

Phase <name> Start

Phase End

Phases have a name that you can customize and specify in their start flags. These names are displayed to the experimenter when running the experiment, and listed in reports of study data. Phase names cannot contain any spaces. Phase end flags do not specify the name of the phase, but simply end the phase that was most recently started (i.e. the current phase).

The below example is what phases and trials could look like in a simple visual fixation study, with a fixed-length familiarization passage followed by two test trials in a fixed order.

STEP 1
Phase Familiarization Start
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 2
VIDEO CENTER OFF

STEP 3
Trial Start
VIDEO CENTER checkerboard ONCE
AUDIO CENTER passage ONCE
UNTIL FINISHED

STEP 4
Trial End
Phase End

STEP 6
Phase Test Start
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 7
Trial Start
VIDEO CENTER checkerboard ONCE
AUDIO CENTER familiar_words LOOP
UNTIL SINGLELOOKAWAY familiar_words GREATERTHAN 2000
UNTIL TIME 25000

STEP 8
Trial End
VIDEO CENTER OFF
AUDIO CENTER OFF
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 9
Trial Start
VIDEO CENTER checkerboard ONCE
AUDIO CENTER unfamiliar_words LOOP
UNTIL SINGLELOOKAWAY unfamiliar_words GREATERTHAN 2000
UNTIL TIME 25000

STEP 10
Trial End
Phase End

Without placing any phase start and stop markers in your protocol files, your experiment will be considered to be a single phase, with all its trials analogous to each other.

The first and most common type of tag is a tag that directly references a file (image, audio, or video) on your computer. These tags are defined before the beginning of the first phase or step, and once defined, cannot be changed later in the protocol: they are linked to only that particular file.

LET <tag> = "<filepath>"

LET dog_image = "C:\Users\ldev\Desktop\ExampleStudy\dog.png"
LET dog_audio = "C:\Users\ldev\Desktop\ExampleStudy\look_at_the_dog.wav"
LET baby = "C:\Users\ldev\Desktop\ExampleStudy\baby.wmv"
LET checkerboard = "C:\BITTSy-Stimuli\checkerboard.wmv"

Filepaths

To easily find the complete file path for your stimuli:

1. Open the folder where the files are located

2. Right-click on a file and select Properties

3. The filepath is shown under "location" and can be copied directly

There is no requirement for stimuli files to be located in the same folder as protocol files, so if you prefer to have spaces in names for other folders (or don't want to disrupt file references for other experimental software on your computer), you can store stimuli files for BITTSy in a separate, dedicated set of folders, such as directly on the C: drive.

LET checkerboard = "C:\BITTSy-Stimuli\checkerboard.wmv"

TYPEDLET and LINKED tags

When you set up these types of tags with LET statements, BITTSy doesn't immediately store information about what kind of file it is (image, audio, or video) other than by storing the file path and extension. There is a special way to declare a tag that allows you to tie the tag name to a particular stimulus type.

TYPEDLET <type> <tag> = "<filepath>"

Here, <type> can be image, audio, or video.

Tags defined with TYPEDLET (as opposed to LET) can be used in any type of group, but only tags defined with TYPEDLET can be made into LINKED tags.

LINKED tags make it easier to reference pairs of stimuli that should be presented together. They are useful in cases where:

• you will want to present particular, limited combinations of stimuli (e.g. each image stimulus goes with one or two possible audio files out of a much larger set in the study, and would never be presented with any of the others)

• stimuli in the pairings are consistently of different types (image/audio/video) [no two stimuli of the same type can be LINKED together]

• you want to randomize presentation order across stimulus pairs rather than randomizing across stimulus types (such as audio and image) independently of each other

TYPEDLET image dog_image = "C:\Users\ldev\Desktop\ExampleStudy\dog.png"
TYPEDLET audio dog_audio = "C:\Users\ldev\Desktop\ExampleStudy\look_at_the_dog.wav"

LINKED dog = {dog_image, dog_audio}

Choose statements and dynamic tags

The syntax above shows how to create a dynamic tag. The name you give it within the LET statement is its new name: this will be what you use later to refer to whatever tag or stimulus was selected. The part in parentheses on the right side of the equals sign is the choose statement (we'll talk more about the syntax and options for choose statements later.)

In the example above, we have a group dogs that contains several tags referencing image files. We want to pick a random one and display it. We don't know which tag out of the group dogs will be chosen on any given run of this particular STEP. Therefore, we can't refer to the result by directly using any of the tags referencing files (dalmatian, deerhound, boxer, etc.) Instead, we create a dynamic tag, to which we can assign whatever tag we randomly select.

Dynamic tags keep referring back to the same tag until a later choose statement changes their reference - that is, the arrow stays pointing in the same direction until another choose statement moves it. If beagle was selected above, you could refer to dog many steps later and it would still mean beagle, as long as there were no intervening choose statements that also assigned their result to dog. If there were more choose statements that assigned to the same dynamic tag, dog would always refer to the result of the most recently-executed choose statement.

Fixed order and random order

Whenever you create a choose statement, you must specify whether to choose the items from the group in order (by always selecting the FIRST tag that is eligible for selection), or to select in a random order (using the flag RANDOM).

More on these and how they work in different types of choose statements below!

Selection without replacement

Choosing items with RANDOM, as in the example above, does just that - picks any random remaining tag in that group, with equal probability.

Choosing items in order, via FIRST, is really designed for choosing without replacement with TAKE. Doing this allows you to set up a particular, fixed order of tags while defining the group, and then present those tags in that order. For example, the items from this group...

...would display dalmatian, then deerhound, then boxer - the order in which they appear in the definition of dogs. This set-up is completely deterministic, which means you could equivalently set up your protocol to directly reference the static tags:

However, when designing experiments that present files in a fixed order, there are often multiple fixed-orders to create and assign across study participants. Using choose statements with FIRST allows you to refer back to these tags generically within the steps of the protocol. Therefore, when you are creating multiple fixed-order protocols for one experiment, all you need to do is change one line: the group definition.

Selection with replacement

Choosing from groups with FROM marks the resulting tag as having been chosen, but does not bar it from being selected again from that group later.

For example, selecting with FROM dogs RANDOM two times on the following group...

...could result in:

dalmatian, deerhound dalmatian, dalmatian deerhound, dalmatian deerhound, deerhound

Selecting with FROM dogs FIRST, on the other hand, would always yield dalmatian.

Repeat clauses

There are additional clauses you can add to a FROM statement that place restrictions on the repeated selection of tags.

These repeat clauses are:

max <number> repeats

This type of clause allows you to restrict how many times a particular item is selected from a group, overall.

This means that each side, LEFT or RIGHT, can be chosen for stimulus presentation up to 5 times. Once one side has been picked 5 times, any remaining repetitions will be forced to pick the other side. There are valid sides remaining for exactly 10 selections; if this step is executed 11 times, BITTSy will crash on the last one because it won't be allowed to pick either one!

Selecting {with max 0 repeats} in a FROM statement is completely equivalent to using a TAKE statement - it specifies to not allow repeats, which is what selecting without replacement is! TAKE is just shorter to write, and easier for someone reading your protocol to understand.

max <number> repeats in succession

This type of clause allows you to restrict how many times a single item can be chosen from a group in a row.

In the above example, each side can be chosen up to 3 times in a row. Whenever one is chosen 3 times in a row, the next selected side must be the other one.

Using {with 0 repeats in succession} specifies to never make the same selection twice in a row. For a group that contains just two items, like sides in our example, this forces selections to alternate.

max <number> repeats in <number> trials

This type of clause can be used when you wish to restrict how many times an item can be repeated within a particular window of trials.

This means that in any set of four consecutive selections, each item can appear a maximum of two times. For example, this would be a valid possible selection order:

boxer, bulldog, bulldog, beagle, dalmatian, bulldog, deerhound

Because every set of four contains only up to two of the same item.

{boxer, bulldog, bulldog, beagle}, dalmatian, bulldog, deerhound boxer, {bulldog, bulldog, beagle, dalmatian}, bulldog, deerhound boxer, bulldog, {bulldog, beagle, dalmatian, bulldog}, deerhound boxer, bulldog, bulldog, {beagle, dalmatian, bulldog, deerhound}

This type of clause is good for when you want to restrict how frequent one thing can be within a certain time frame, beyond whether they are strictly all in a row (which is repeats in succession).

Here's another example.

This means that as each item is selected, it cannot be selected again in any of the next 5 selections that are made from that group. For example, if boxer is chosen first, it cannot appear again until trial 7 at the earliest; beagle, if chosen second, cannot appear again until trial 8, and so on.

On the surface, the above example might seem like a good way to create a block structure in BITTSy (displaying all of the stimuli from a set in a random order without repeats, then showing the set again in a different random order). However, you would typically want stimuli within a block to be randomized independently, and this selection criteria always works along a moving window, meaning that there is never a point where the current selection is independent of the previous ones. For example, if repeated executions of the above line made the following selections:

whippet, dalmatian, deerhound, beagle, boxer, bulldog, ______

Because the last selection is considering the five previous, and won't allow any repeats within that frame...

whippet, {dalmatian, deerhound, beagle, boxer, bulldog, ______}

...that selection must be whippet - it is the only item that wouldn't be a repetition within that set of most recent 6 picks - and next would have to be dalmatian, and then deerhound... Essentially, what you get is a random permutation of the six items when moving through the group for the first time, but thereafter it repeats that same ordering of the six tags.

How, then, do you make a block structure with BITTSy? See below!

Selection and groups of groups (and groups of groups of groups!)

Let's go back to the basic formulation of a choose statement.

Let's say we're writing a protocol in which we want to display one of these images. We start with animals, a group whose members are other groups. We need two choose statements before we can display an image tag - first to select either mammals or reptiles out of animals, and second to select a particular mammal or reptile from that resulting group (which we've called class).

Now let's say we want to make an experiment that displays these images in a block structure. One block of trials will be mammals, one will be reptiles. We'll randomly select which block comes first, and within each block, we'll randomly order the two animals that belong to that phylogenetic class. Below is an example of how this can be constructed.

Defining animals as a group of groups allows you to set up choose statements that create this type of simple block structure, and gives the following possibilities.

Action statements start or stop the presentation of stimuli. They are used to control the displays, lights, and speakers.

Media files that are presented in action statements in one STEP persist through that step and into subsequent ones until they are instructed to turn off, either by reaching the end of the file (for audio and video files that are set to play only once) or by including a corresponding action statement later in the protocol that turns the stimulus off.

Images

IMAGE <side> <tag>
IMAGE <side> OFF

IMAGE CENTER dog
IMAGE LEFT OFF

Videos

VIDEO <side> <tag> <LOOP or ONCE>
VIDEO <side> OFF

VIDEO CENTER checkerboard LOOP
VIDEO CENTER OFF

ONCE will play the file to the end, then remove the video from the screen (it is not necessary to use a VIDEO <side> OFF statement to remove it, but doing so will not cause any problems). LOOP will continue looping back to the start whenever the file ends, and continue replaying the file until the next VIDEO <side> OFF statement.

Audio

AUDIO <audio channel or STEREO> <tag> <LOOP or ONCE>
AUDIO <audio channel or STEREO> OFF

AUDIO LEFT music1 ONCE
AUDIO RIGHT OFF 

As with video, ONCE will play the file to the end, then stop the audio from presenting to the speaker(s) (it is not necessary to use an AUDIO <side> OFF statement to remove it, but doing so will not cause any problems). LOOP will continue looping back to the start whenever the file ends, and continue replaying the file until the next AUDIO <side> OFF statement.

Stereo (2.1) audio systems

In a stereo audio system, channels are LEFT and RIGHT. Protocols run with stereo audio systems can also use the keywords CENTER and STEREO. Both of these commands will play audio simultaneously from the left and right speakers.

AUDIO CENTER passage LOOP
AUDIO STEREO passage LOOP

Multichannel (5.1 or 7.1) audio systems

AUDIO LEFTBACK passage LOOP

It is important to note that while in a stereo 2.1 system, STEREO and CENTER mean the same thing, they are not assumed to be the same thing whenever a multichannel AUDIO starting definition is provided. In this case, STEREO is the only command that means to play from two speakers simultaneously (these will be the first two speakers defined in the AUDIO starting definition, which are designated the front left and front right speakers on sound cards). CENTER can be used as a name in the AUDIO starting definition to mean a particular speaker, and if it is not present in the starting definition, it is not considered a valid channel name.

A note on STEREO/CENTER

AUDIO STEREO music ONCE

Using the above command, in a single action statement, ensures temporal synchrony in presenting the audio file across the left and right speakers. Two separate action statements playing tags to separate channels do not ensure complete synchrony. When playing a single tag to left and right, STEREO (or CENTER, for a 2.1 system) is therefore always preferable.

Whenever it is crucial that two different audio streams begin to play simultaneously, it is better to use audio files in which these streams have already been mixed together/placed into separate channels (as desired), and use a single action statement to play this file.

Action statements using LINKED tags

LINKED dog = {dog_image, dog_audio}

Creating these tags via TYPEDLET and LINKED allows you to use action statements that refer to these tags in the same way across action statements of different types.

IMAGE LEFT dog
AUDIO LEFT dog ONCE

In protocols where they are suitable, LINKED tags help cut down on the number of tag names to which you must directly refer.

General window settings

WINDOWSIZE

This defines the number of trials which constitute a window. The same size is used when evaluating potential basis windows and criterion windows.

There is no default value for window size. This setting must be specified in the protocol of any habituation procedure that uses basis and criterion windows.

WINDOWTYPE

This setting defines whether windows for evaluation as possible basis/criterion windows should overlap with each other. SLIDING allows overlapping windows, while FIXED does not. For example, with a WINDOWSIZE of 3 and the window type FIXED, trial sets 1-3, 4-6, 7-9, etc. will be evaluated; if SLIDING, trial sets 1-3, 2-4, 3-5, 4-6, 5-7, etc. will all be evaluated.

SLIDING is the default setting if the WINDOWTYPE is not defined within a protocol.

WINDOWOVERLAP

This setting defines whether the basis window and a criterion window are allowed to overlap. This setting is important whenever WINDOWTYPE is SLIDING; it is irrelevant for FIXED windows.

If this setting is YES to allow overlap, and the WINDOWSIZE was 4, you could have a basis window of trials 1-4 and trials 2-5, 3-6, 4-7, etc. would all be evaluated as possible criterion windows. But if WINDOWOVERLAP was set as NO, the first window to be evaluated as a potential criterion window would be trials 5-8. All prior windows would be disallowed because they would include trial 4, which was part of the basis window.

YES is the default if WINDOWOVERLAP is not defined in the protocol.

Basis window-specific settings

BASISCHOSEN

Defines which window is chosen as the basis window. This can either be the first window or the window with the longest total looking time.

LONGEST is the default if BASISCHOSEN is not specified.

BASISMINIMUMTIME

This setting allows you to set a minimum total looking time for a basis window. This can help prevent a child who is fussy at the start of an experiment from reaching a habituation criterion without having met a minimal requirement for looking time.

Zero milliseconds is the default, i.e. no minimum.

Criterion window-specific settings

CRITERIONREDUCTION

This value is a multiplier between 0 and 1, exclusive. It can be expressed as a decimal with or without a leading zero.

An error is thrown if CRITERIONMET is used as a terminating condition without a definition of CRITERIONREDUCTION being present in the protocol.

Looking time settings

BITTSy allows you to specify under what conditions to end one STEP and move on to the next one. These step terminating conditions are used to control the experiment flow from step to step within your protocol.

Basics

STEP 1
Phase Training Start

STEP 2
LIGHT CENTER BLINK 200
UNTIL KEY C

Sometimes you don't need to wait for any particular condition to be met before moving on to the next step. When a step has no terminating condition, execution proceeds to the next step immediately (STEP 1 to STEP 2 in the example above).

When you want your experiment to wait for something, that's when you'll use a step terminating condition. These are UNTIL statements, and should be understood as "don't move on to the next step until the following conditions are true."

When a step has terminating conditions, these must be the last lines in that step. Once the specified terminating condition(s) are fulfilled, execution proceeds immediately to the next step. Therefore, the next thing you want to happen should be placed at the start of the step that follows.

STEP 2
LIGHT CENTER BLINK 200
UNTIL KEY C

STEP 3
AUDIO CENTER familiarization ONCE
UNTIL SINGLELOOKAWAY familiarization GREATERTHAN 2000

STEP 4
AUDIO CENTER OFF

Types of terminating conditions

KEY

UNTIL KEY <key>

Valid keys are alphanumeric, plus arrow keys (denoted by the names UP, DOWN, LEFT, and RIGHT). Number and arrow keys correspond to keys on the main keyboard, not the number pad. Letter keys should be capitalized.

UNTIL KEY X

UNTIL KEY L

TIME

UNTIL TIME <time in milliseconds>

This terminating condition allows the step to end after a specified amount of time. The time is counted from the point when the step starts. Remember, time is in milliseconds! (So 20 seconds would be listed as 20000).

UNTIL TIME 25000

FINISHED

UNTIL FINISHED

This terminating condition checks whether all the media files (audio/video) that began to play in the current step have finished playing, and only allows execution to move on to the next step once they have ended.

Below are two examples of how this could be used in a study with an audio familiarization passage that is presented with an unrelated video to help maintain the participant's attention.

STEP 1
AUDIO CENTER familiarization ONCE
VIDEO CENTER animation ONCE
UNTIL FINISHED

In the above example, the step would only end once both the video and familiarization passage had ended.

STEP 1
VIDEO CENTER animation LOOP

STEP 2
AUDIO CENTER familiarization ONCE
UNTIL FINISHED

STEP 3
VIDEO CENTER OFF

And in this example, STEP 2 would end when the audio file was finished playing, but would not wait for the video file to be finished (and thus instructs for this video to be turned off in the next step).

The first example would be suitable for a study in which the passage and the video were made to be the same length. The second example is better for use where the video file is a different length - either shorter and needing to be played on LOOP , or longer and can be played ONCE, but it is not necessary to wait for it to play all the way to the end before going to the next step.

Looking-based conditions

Often you may want BITTSy to wait until the child does something - either the child has looked at something for a sufficient length of time, or has looked but then looked away for a certain length of time, etc. There are four basic types of looking behavior that can serve as a trigger: a single look of a particular length, a total amount of (cumulative) looking of a particular amount, a single look away of a particular length, or a total amount of time spent looking away. These are done with the keywords SINGLELOOK, SINGLELOOKAWAY, TOTALLOOK, and TOTALLOOKAWAY.

For all of these, you must also specify a tag - it must be clear what the child should be looking toward or away in order to be tracked for these terminating conditions.

SINGLELOOK

UNTIL SINGLELOOK <tag> GREATERTHAN <time in milliseconds>

This terminating condition is met whenever the experimenter records via keypress a single look in the direction where the given tag is being presented that exceeds the given time in milliseconds. The look must end (the experimenter presses a key that indicates a different direction, or the tag is no longer actively being presented) before the step will end and the next begin - the step is not cut off as soon as the threshold is met.

The tag given in this terminating condition can be of any type (denoting a particular file, a group, or a dynamic tag).

STEP 1
LET trialaudio = (TAKE trialaudiolist RANDOM)
AUDIO LEFT trialaudio ONCE
UNTIL SINGLELOOK trialaudio GREATERTHAN 5000

SINGLELOOKAWAY

UNTIL SINGLELOOKAWAY <tag> GREATERTHAN <time in milliseconds>

This terminating condition is met whenever the experimenter records via keypress a single look in a direction where the given tag is NOT being presented that exceeds the given time in milliseconds. The look away does not have to switch to a new direction before the terminating condition is met; it will be cut off at the specified time.

STEP 1
LIGHT LEFT BLINK 200
UNTIL KEY L

STEP 2
AUDIO LEFT training ONCE
UNTIL SINGLELOOKAWAY training GREATERTHAN 2000

In the case above, where the key L is assigned to LEFT, the left light would blink until it got the participant's attention and the experimenter indicated they had turned to the left. Then, the audio would begin playing. Because the step could only start when the participant is looking left, there must be a change in their looking (that lasts for at least 2 seconds without looking back to the left) before the step can end.

TOTALLOOK

UNTIL TOTALLOOK <tag> GREATERTHAN <time in milliseconds>

This terminating condition is met whenever the participant accumulates the specified amount of time looking in the direction of the given tag during the current step.

STEP 1
AUDIO LEFT passage LOOP
UNTIL TOTALLOOK passage GREATERTHAN 20000

STEP 2
AUDIO LEFT OFF

In the above example, the step continues (and the audio continues to loop) until the participant looks towards it for a total of at least 20 seconds. This could occur with a single look that lasts longer than 20 seconds, or could accumulate across any number of shorter looks until the total reaches this threshold. Each look in the given direction must end (the experimenter presses a key that is not assigned to that direction) before being added to the running total and checked for whether it exceeds the threshold; the step will not end while the participant is still looking toward the given tag.

TOTALLLOOKAWAY

UNTIL TOTALLOOKAWAY <tag> GREATERTHAN <time in milliseconds>

This terminating condition is met whenever the participant accumulates the specified amount of time looking away from the direction of the given tag during the current step.

STEP 1
AUDIO LEFT passage LOOP
UNTIL TOTALLOOKAWAY passage GREATERTHAN 10000

STEP 2
AUDIO LEFT OFF

As covered above for SINGLELOOKAWAY, any keypress that is not associated with the side the tag is being presented on is treated as "away" from that tag.

Using multiple terminating conditions

OR combinations

For steps that can end one of two ways, the step terminating conditions should be listed on two separate lines, one after the other.

STEP 1
AUDIO CENTER passage ONCE
UNTIL FINISHED
UNTIL SINGLELOOKAWAY passage GREATERTHAN 2000

In the example above, the step ends when either the audio file runs out OR the participant looks away from that direction for at least two seconds - whichever happens first.

AND combinations

For steps must meet multiple conditions before ending, the terminating conditions get put on one line and are joined by "and".

UNTIL TIME 25000 and KEY X

In the above example, the step would have to last for at least 25 seconds and the experimenter would have had to press a key, either anytime before the 25-second mark (in which case the step would end at 25 seconds), or after the 25 seconds have elapsed (in which case it would continue for however long until the key was pressed). A condition like this would ensure that a minimum time is always met, but allow an experimenter to draw out the step for longer until a particular cue comes (e.g. when waiting for a certain behavior).

Complex combinations

You can use both of the above combination types on the same step, for even more nuanced end conditions for steps.

UNTIL <condition 1> and <condition 2> ... and <condition N>
UNTIL <condition A>
UNTIL <condition B>
...

UNTIL TIME 5000 and KEY X
UNTIL TIME 25000

In the above example, the step must last at least 5 seconds and a maximum of 25 seconds. If the experimenter presses the indicated key anytime before the maximum time, the step can end immediately when the first condition is satisfied; otherwise, it ends when the second condition, reaching 25 seconds, is met. A combination of conditions like this ensures minimum and maximum times for the step, but allows the experimenter to indicate whether the step should end earlier than the maximum time.

How loops work

Experiments done with infants and toddlers usually consist of a series of trials, in which the stimuli used or side of presentation may vary from trial to trial, but the core structure of every trial is the same. Rather than writing a long protocol file that separately specifies every trial with a unique set of steps, you can specify the trial structure once, then use a loop to repeat it.

A LOOP statement will cause the steps in between the specified step number and the step in which the LOOP statement is defined to be executed. This occurs repeatedly, until the loop statement's terminating conditions have been satisfied.

LOOP STEP <number>
UNTIL <terminating condition>

The following example is the entire test phase of a preferential looking study with trials shown in a fixed order. The entire study runs via looping over a set of 3 steps that comprise an attention getter and a trial.

STEP 1
Phase Test Start

STEP 2
VIDEO CENTER attentiongetter LOOP
UNTIL KEY X

STEP 3
VIDEO CENTER OFF

STEP 4
Trial Start
LET trial_stim = (TAKE stim_list FIRST)
VIDEO CENTER trial_stim ONCE
UNTIL FINISHED

STEP 5
Trial End
LOOP STEP 2
UNTIL 23 TIMES

STEP 6
Phase End

When running the protocol, we begin, as always, at STEP 1. The test phase starts, and the first attention getter video plays until the experimenter indicates the participant is ready for a trial. The first trial stimulus is chosen from the list of stimuli, displayed, and played to the end. The loop step (the step that contains the LOOP statement) is STEP 5. When it is reached, execution jumps back to STEP 2, and proceeds again through steps 3 and 4, and onto 5. Upon reaching the LOOP statement again, it again jumps back to 2, and proceeds through the steps. This repeats a total of 23 times, displaying a total of 24 attention-getters and trials (the one original execution of steps 2-4, plus the 23 times it looped over that sequence.)

Loops can be nested within each other, allowing for concise specification of experiments with a block structure. Below is the test phase of a headturn preference study that consists of 3 blocks. Each block is comprised of 4 trials, for a total of 12 trials. Before each trial, the participant is oriented to a neutral position (center), and then the trial begins once they reorient in the direction where the light has begun flashing and from which the audio will play.

...
STEP 9
Phase Test Start

STEP 10
LET thisblock = (TAKE testblocks FIRST)

STEP 11
LIGHT CENTER BLINK 200
UNTIL KEY C

STEP 12
LIGHT CENTER OFF

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

STEP 14
Trial Start
LET trialaudio = (TAKE thisblock RANDOM)
AUDIO side1 trialaudio ONCE
UNTIL FINISHED
UNTIL SINGLELOOKAWAY trialaudio GREATERTHAN 2000

STEP 15
Trial End
AUDIO side1 OFF
LIGHT side1 OFF

STEP 16
LOOP STEP 11
UNTIL 3 TIMES

STEP 17
LOOP STEP 10
UNTIL 2 TIMES

STEP 18
Phase End

Steps 11-15 specify a sequence of centering the participant and playing a trial, which is a unit that repeats throughout the experiment. These steps are looped over in STEP 16, which specifies to execute this sequence three additional times so that the first block contains four trials. Once the first block is finished, the LOOP statement in STEP 17 is reached, which has it jump back to STEP 10 to select the next block of stimuli to present. The inner loop in STEP 16 is executed just as before, playing the four trials in this block also. STEP 17 is reached again, and execution jumps back to STEP 10 to select the third block, and the nested loops work in the same way to play four trials here. Now that STEP 17 has had its loop repeated the required two times, we move to STEP 18 and the phase ends.

Loop terminating conditions

LOOP STEP <number>
UNTIL <terminating condition 1> and <terminating condition 2>

Or by an OR, such that only one condition need be met before ending the loop.

LOOP STEP <number>
UNTIL <terminating condition 1>
UNTIL <terminating condition 2>

TIMES looped

LOOP STEP <number>
UNTIL <number> TIMES

This loops back to the specified step, executes all the intervening steps in order, and loops again until it has completed the entire loop the specified number of times. For example,

STEP 1
LET dog = (TAKE dogs RANDOM)
IMAGE CENTER dog
UNTIL 5000

STEP 2
LOOP STEP 1
UNTIL 5 TIMES

The above loop would execute STEP 1 five times, in addition to the first execution before the loop step was reached. Therefore, we would select and display an image from the group dogs a total of 6 times.

EMPTY

Rather than specifying a set number of times to loop, you can also loop until a particular group has no remaining options for selection.

LOOP STEP <number>
UNTIL <group tag> EMPTY

For example,

LET dogs = {dalmatian, deerhound, boxer, bulldog, beagle, whippet}

STEP 1
LET dog = (TAKE dogs RANDOM)
IMAGE CENTER dog
UNTIL 5000

STEP 2
LOOP STEP 1
UNTIL dogs EMPTY

The above loop would run until all the tags in dogs have been marked as selected, and none are eligible to be chosen by the TAKE statement - in this case, the loop would repeat 5 times, in addition to the first selection, for a total of 6 items displayed.

TIME elapsed

It is also possible to execute a loop until at least a certain amount of time has elapsed since the looping began.

LOOP STEP <number>
UNTIL TIME <time in milliseconds>

STEP 1
LET dog = (FROM dogs RANDOM)
IMAGE CENTER dog
UNTIL 5000

STEP 2
LOOP STEP 1
UNTIL TIME 55000

In the above example, images are selected randomly (with replacement) and displayed for 5 seconds each, with the section looped for a total of 55 seconds. Importantly, the timer for the loop begins when the UNTIL statement is reached for the first time - which is after the first tag from dogs is selected and displayed for 5 seconds. Therefore, images of dogs are displayed for a total of 60 seconds.

Like all loop termination conditions, UNTIL TIME conditions are only evaluated when execution reaches the loop step (STEP 2, in the above example) again. If the specified time is met in the middle of a loop sequence, the current run of the loop will be allowed to finish before the terminating condition is met and execution continues to later steps in the protocol file.

KEY

As of BITTSy version 1.33, you can also loop until a particular key is currently active.

LOOP STEP <number>
UNTIL KEY <key>

It is important again to note that loop terminating conditions are evaluated only when execution reaches the loop step. Therefore, if the loop was set to run UNTIL KEY X, and the experimenter pressed X followed by another key while the loop was still executing, the loop would not end: when the terminating condition was checked, some other key was the most recent key.

This terminating condition is useful in cases in which you wish to use a loop to run through a set of trials until an experimenter makes some judgment that the child is "done." For example, this could be used for an experimenter to end a phase if some more desirable terminating condition (e.g. accumulated looking time) cannot be met, while still allowing the child to continue to participate in the subsequent parts of a study. It can also be used for studies in which the variable of interest is how many trials are shown before the child makes some overt behavioral response, such as imitating a person on a screen, pointing, or saying an answer.

Looking-controlled end conditions

Often we want to repeat the presentation of a stimulus or set of stimuli until the child has reached a particular level of attention toward the stimuli - either they've looked a set amount, or they've reached a particular point of boredom or inattention. This can be achieved by setting up these trials within a loop, and looping until some looking-controlled end condition is met.

TOTALLOOK

LOOP STEP <number>
UNTIL TOTALLOOK <tag> GREATERTHAN <time in milliseconds> THIS PHASE

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

TOTALLLOOKAWAY

LOOP STEP <number>
UNTIL TOTALLOOKAWAY <tag> GREATERTHAN <time in millseconds> THIS PHASE

This works identically to TOTALLOOK, but rather than totaling up time when an experimenter indicated the participant was looking at the given tag as it was presented, uses the time spent not looking toward the tag. Time when the tag was not active (not being displayed/played) does not count as time looking away from that tag; only time when the child could have been looking at it but was recorded as looking some other way (with any key that was not assigned to the tag's current side) is counted.

CRITERIONMET

LOOP STEP <number>
UNTIL CRITERIONMET

JUMP basics

What is JUMP?

JUMP clauses are a very powerful option introduced in BITTSy version 1.5. Ordinarily, BITTSy protocols progress linearly through the STEPs that you write - the entire protocol is executed (with the exception of LOOPs) line-by-line, in the order they appear in the protocol file. JUMP clauses allow there to be new and different paths through an experiment: STEPs can be skipped over, repeated, or executed out of order. Different participants can experience different parts of the protocol in different orders, depending on conditions that you specify. This opens up a wide new range of possible experiments in BITTSy.

By default, once the UNTIL conditions of a STEP are met, the experiment progresses to the next step of the protocol, in order. Adding an optional JUMP clause to the UNTIL statement allows you to change this, and specify a different step in the experiment that should be executed next, after that condition is satisfied.

When can a JUMP clause be used?

JUMP clauses must always be embedded in UNTIL statements. They cannot occur on their own, to mean that execution should always jump to the specified step - they must depend on a condition being met. But you can achieve the same goal (a JUMP that always executes, immediately) by having that condition be something that you know will already be true at that point in your experiment, or specifying a wait time of a single millisecond.

Where can a JUMP go to?

The specified step to JUMP to can be either before or after the current STEP number. That is, a JUMP that is specified in an UNTIL statement at the end of STEP 5 could cause execution to skip backwards to an earlier step, or to anywhere later in the protocol.

It is possible to specify a jump to the same step that the JUMP clause itself is in - in this case, the same step is restarted from its beginning. However, this is rarely a desired behavior, and may have unintended consequences during steps in which stimuli are active and participants' looking time is being tracked. More commonly, to repeat the most recent part of an experiment, you would jump back to at least one STEP prior.

JUMP usage in complex terminating conditions

both terminating conditions would need to be met in order for a jump to the specified step to occur. (That is, the experimenter would have to press the X key during a trial in which the participant had looked at the stimulus for less than 5 seconds. Only then would STEP 11 be the next step to be executed.)

JUMP clauses are optional - not having one always means to simply progress to the next STEP in order. You can always leave them out when that is the intended behavior, including within a combination of terminating conditions.

Potential pitfalls with JUMP

You will need to be careful to think through all of the ways you've set your experiment to progress, and make sure that all of these are well-formed. Below are some of types of errors that you should look for when using JUMP:

• Creating an experiment that doesn't end. If your JUMP clauses allow you to jump backwards or repeat sections of the study, check that you don't accidentally create an infinite repetition, or make any series of jumps that will result in never reaching the end of the protocol!

Example uses of JUMP

This section walks through a variety of cases in which JUMP clauses are particularly useful, or create experiment structures that cannot be achieved with a BITTSy protocol that progresses through steps in a strictly linear fashion. These examples are meant to illustrate some possibilities opened up by using JUMP, but are by no means exhaustive!

Ending a phase or loop early

The example below runs three trials, each selecting a video to play out of a different group. The pattern is looped an additional 8 times, for a total of 27 trials.

Repeating a trial

Sometimes you may want the ability to repeat the same trial again, for example in a familiarization or training phase of an experiment if the participant isn't paying attention or if a trial is started early by an experimenter mistake. A JUMP clause can be used to repeat trials according to an experimenter's decision during the study session (i.e. a particular key is pressed to repeat the trial) or according to external or looking-time criteria.

In the example below, the experimenter must decide after a trial to continue the experiment normally (by pressing C) or to repeat the trial (by pressing X). Because the jump goes to STEP 2 and does not repeat STEP 1, where the stimulus video is randomly selected, the same stimulus will be shown again on the repeated trial.

Repeating a phase

Similar to repeating a trial, there may be situations where you'd like to repeat a whole phase of the experiment - for example, to re-run a familiarization phase if the experimenter feels the participant is not yet comfortable with how the task works.

In the example below, four familiarization trials are played. At the end of the phase, the screen stays blank until the experimenter selects whether to continue on to the test phase as normal (pressing C) or to repeat the familiarization phase (pressing X).

In the above example, it's important for the experimenter to know that they are supposed to make a choice when the phase ends, and which keys to press for which phase! Reminders can be put in comment lines (any line that begins with a #, which is ignored by BITTSy when validating and executing protocols) at the beginning of a protocol, so that they are visible after the protocol is loaded. The name of the current phase is also displayed in the experimenter's window, so signaling them with a new phase name may make the timing of this choice more obvious.

If you wanted instead to let the experimenter decide mid-trial to stop and restart the familiarization phase, you could adapt the example like below. Like the second example in the previous section on repeating a trial, we define two separate steps that end the trial, with STEP 3, the option that also ends the phase and restarts it, only happening if the experimenter presses X during a trial.

Skipping a phase

Sometimes, when a particular condition is met, a phase or section of the experiment can be skipped entirely. For example, in habituation studies, participants who do not meet criteria for habituation are typically excluded from all analyses of looking time in the test phase. Sometimes it is desirable to show the test trials anyway if there are only a couple of them, so that the parent observing the study can see it end as originally described. But if it would be preferable in your study to not make the participant go through any extra trials when you know the data won't be used, you can use a JUMP statement to skip to the end of the study depending on the participant's habituation status.

Events based on participant choice or discrete behavior

The example below begins by having the experimenter press L or R to indicate when the participant turns to look to the left or right side of the testing booth. Whichever key is pressed first, a video will be displayed to a screen on the same side where the participant is now looking, and the video stops when they look away briefly. This lets us display stimuli in a way that is responsive to a cue from the participant.

This is a simple example, with only a couple steps in each of the two "branches" that can execute based on different criteria - but it is possible to construct much more complex sequences of steps that are skipped in one case and executed in another, with more than two branches, branches within other branches, etc. BITTSy's STEP numbers, which only label steps and do not reflect their order of execution when JUMP clauses are being used, can start to look confusing in these cases - and you'll want to keep track of which step numbers represent important events in your experiment, as well as the context of when they happen. Constructing a flowchart is very useful for this! This one represents the example above.

This kind of setup could be used similarly to "reveal what's behind a door" by having the experimenter record a child's selection (either from gaze direction or pointing behavior) with a keypress, then displaying an animation on the screen that the child picks.

Progressing based on consecutive criteria

Some experiments may require a particular sequence of conditions to be met, and other conditions to not be met in-between, before moving on to another phase of the experiment. For example, in a study with a "correct" or desired response, you might require three correct responses in a row before moving on from the training phase.

Often such studies will be constructed so that experimenters can remain blinded to which participant behaviors are considered correct. But for a simple example of this kind of protocol structure, imagine a study where during each training trial, the experimenter waits for one of two behaviors, and records either a C keypress for "correct" or M for "mistake." The participant must get three correct trials in a row to keep going in the study, and training trials continue until they achieve this, or get 10 wrong in a row.

STEP 3 is a trial like any other, yet it is only executed when the participant has a current streak of one correct response. Another correct response leads to a jump to STEP 5, which is only executed when the participant has a current score of two correct responses in a row. And a correct response recorded in STEP 5, bringing us to three correct responses in a row, is the only way to get to STEP 7, which begins the next phase of the experiment. But an incorrect response in either STEP 3 or STEP 5 breaks the streak and lands the execution back in STEP 1, which represents a current streak of zero.

This structure can be visualized in a flowchart like below:

Events based on accumulated looking time

Studies with familiarization or training phases often require the participant to accumulate a certain threshold of looking time toward a set of stimuli before moving to the next phase. Sometimes you only care about total time attending to the set as a whole, and it doesn't matter whether the participant looks much longer at some than others. But sometimes you want the looking time to end up relatively balanced. In these cases, once one stimulus reaches the threshold, you can use a JUMP statement to repeat another one that's below the threshold, until the participant meets the required looking time to that one too.

This is commonly needed in headturn preference procedure experiments with an initial exposure phase that involves a couple of passages. Typically the passages alternate trials or are ordered randomly - but if the participant reaches the required exposure for one passage very early on, we don't want them to keep hearing that passage more and more while trying to reach the threshold listening time on the other passage. The example below is based on the familiarization phase of this headturn preference example, but rather than alternating trials and looping in STEP 6 until both audio files achieve 25 seconds of listening time, we only alternate trials until one of them does, then execute either STEPs 7-10 or 11-14 depending on which audio file still needs more listening time.

Habituation studies are ones in which an experiment or phase continues until the child no longer attends (or attends less) to a particular stimulus.

In BITTSy, habituation phases terminate based on your protocol's set termination criteria - a decrease in looking relative to baseline. This, in turn, is based on the following factors:

• How many trials should be included in the baseline measure and in judging whether habituation has occurred (e.g., 3 trials, 4 trials, etc.). Note that the window SIZE (in terms of number of trials) is the same for both.

• Which trials are included in the baseline (e.g,. the FIRST three trials, or the 3 trials with LONGEST looking overall...)

• Percentage drop (e.g., the phase should end when looking has reduced by a certain percentage of baseline, such as 50% of baseline looking)

About this protocol

This protocol is based on the Newman et al. (2020) study cited below, testing toddlers' fast-mapping from noise-vocoded speech via a preferential looking paradigm with an initial training period on the word-object mappings. In a training phase, participants are taught the names for two objects, which appear alternately on the screen. Following training, both objects appear on-screen simultaneously with no accompanying audio to assess baseline preferences and familiarize participants to the idea that the objects will now appear together. Subsequently, the objects appear together in these same positions across several test trials. Sometimes the speaker asks the child to look toward one object ("find the coopa!") and sometimes directs them to look at the other object ("find the needoke!")

Newman, R. S., Morini, G., Shroads, E., & Chatterjee, M. (2020). Toddlers' fast-mapping from noise-vocoded speech. The Journal of the Acoustical Society of America, 147(4), 2432-2441.

Starting the protocol

Starting definitions

DISPLAYS ARE {CENTER}
SIDES ARE {CENTER}

In this protocol, we are only using a single display, and our audio is playing from stereo speakers. We therefore only name one display in the DISPLAYS definition, and leave out the definitions for LIGHTS and AUDIO. We only need to name one SIDE to match with the display.

Tags

Our visual stimuli are two animated 3D models, one of a spikey ball on a pedestal (which we call "spike") and one that looks like an F in profile (which we call "fred"). In training trials, we'll present one of these two objects and an audio track will identify it as either the needoke or the coopa.

LET coopa_fred = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_fred.mp4"
LET coopa_spike = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_spike.mp4"
LET needoke_fred = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_fred.mp4"
LET needoke_spike = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_spike.mp4"

After the training phase, we'll have a baseline trial with both objects on-screen and no accompanying audio. We'll want to randomize which is on the left and which is on the right. In the test phase, to keep the task as easy as possible, we'll keep the object positions the same as in the baseline trial.

This baseline trial has "fred" on the left and "spike" on the right. (The order of objects in our video filenames identify their ordering on screen left-to-right.)

LET silent_fred_spike = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\silent_fred_spike.mp4"

And this baseline trial can be presented with either of these two sets of test videos with that same object positioning, depending on how the objects were labeled in the training phase.

# Fred = Coopa, Spike = Needoke
LET coopa_fred_left = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_fred_spike.mp4"
LET needoke_spike_right = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_fred_spike.mp4"
# Fred = Needoke, Spike = Coopa
LET needoke_fred_left = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_fred_spike.mp4"
LET coopa_spike_right = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_fred_spike.mp4"

Here are the rest of our tags, for the opposite object positioning.

LET silent_spike_fred = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\silent_spike_fred.mp4"
# Spike = Coopa, Fred = Needoke
LET coopa_spike_left = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_spike_fred.mp4"
LET needoke_fred_right = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_spike_fred.mp4"
# Spike = Needoke, Fred = Coopa
LET needoke_spike_left = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\needoke_spike_fred.mp4"
LET coopa_fred_right = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\coopa_spike_fred.mp4"

Note that in our test video tag names, we've labelled which object is the target object and which side is the correct answer. This makes it extremely convenient for us to determine these later, looking at the reports from study sessions - it is directly in the tag name! This is not necessary for this protocol, just nice. It does lead to some redundancy in files - for example, coopa_spike_left and coopa_fred_right are the same video file. Which tag we use to call up that video just depends on which object was named coopa earlier in the study.

Lastly, we'll have an attention-getter video that plays in-between all the trials.

LET attentiongetter = "C:\Users\ldev\Desktop\BITTSy\CIWordLearning\baby.mp4"

Groups

LET order1_train = {coopa_spike, needoke_fred}
LET order2_train = {coopa_fred, needoke_spike}

We're also going to randomly determine which sides the two objects will appear on in baseline and test trials. With this next layer of random assignment, we'll end up with four distinct orders. In the "A" orders, "fred" will be on the left, and in the "B" orders, "spike" is on the left.

LET order1A_baseline = {silent_fred_spike}
LET order1B_baseline = {silent_spike_fred}
LET order2A_baseline = {silent_fred_spike}
LET order2B_baseline = {silent_spike_fred}

Now for the test phase groups. In Order 1A, coopa goes with "spike" and needoke goes with "fred," and "fred" is on the left and "spike" on the right. These are the test video tags that fit that.

LET order1A_test = {coopa_spike_right, needoke_fred_left}

Similarly, we'll set up the test video groups for the other orders.

LET order1B_test = {coopa_spike_left, needoke_fred_right}
LET order2A_test = {coopa_fred_left, needoke_spike_right}
LET order2B_test = {coopa_fred_right, needoke_spike_left}

Now we're ready to define our groups of groups - each whole order, from training to test.

LET order1A = {order1_train, order1A_baseline, order1A_test}
LET order1B = {order1_train, order1B_baseline, order1B_test}
LET order2A = {order2_train, order2A_baseline, order2A_test}
LET order2B = {order2_train, order2B_baseline, order2B_test}

So that we can randomly pick one of these four orders at the start of the experiment, there will be one more layer to this group structure. We'll have a group that contains all of the orders.

LET orders = {order1A, order1B, order2A, order2B}

Optional experiment settings

STEPS for execution

Now that the experiment is set up, we'll define what will actually happen when we click to run the protocol.

Training phase

STEP 1
Phase Train Start
LET order = (FROM orders RANDOM)
LET training_group = (TAKE order FIRST)
LET baseline_group = (TAKE order FIRST)
LET test_group = (TAKE order FIRST)

Now that we've picked an order, time to start displaying stimuli. First, an attention getter. This is played until the experimenter indicates that the child is looking at the screen and ready for a trial to start, by pressing the X key on the keyboard.

STEP 2
VIDEO CENTER attentiongetter LOOP
UNTIL KEY X

STEP 3
VIDEO CENTER OFF

Now that the child is ready to see a trial, let's show one.

STEP 4
Trial Start

STEP 5
LET training_trial = (FROM training_group RANDOM {with max 0 repeats in succession})
VIDEO CENTER training_trial ONCE
UNTIL FINISHED

STEP 6
Trial End
VIDEO CENTER OFF

The group of training videos contains two tags. We'll choose one of them randomly. We use a randomization clause {with max 0 repeats in succession} to restrict which tags are chosen from this group after we make the first selection. This one means that we can never display the same tag in the group twice in a row. Because there are only two in the group, trials will alternate between them: children will either hear coopa, needoke, coopa, needoke... or needoke, coopa, needoke, coopa...

STEP 7
LOOP STEP 2
UNTIL 7 TIMES

When we finish the first trial and reach this loop, we'll jump back to STEP 2, where the attention getter video started, and we'll continue, running another whole trial, until we reach STEP 7 again. This will repeat until the loop terminating condition is reached: when we've looped back over the section seven times. Along with the first execution of this section, before we started looping, we display a total of eight training trials. This is the entirety of the training phase.

STEP 8
Phase End

Test phase

Now we'll start the test phase. We'll still have the attention-getter appear in between every trial, and our first video we show here will be our baseline video.

STEP 9
Phase Test Start

STEP 10
VIDEO CENTER attentiongetter LOOP
UNTIL KEY X

STEP 11
VIDEO CENTER OFF

STEP 12
Trial Start

STEP 13
LET baseline_trial = (FROM baseline_group FIRST)
VIDEO CENTER baseline_trial ONCE
UNTIL FINISHED

STEP 14
Trial End
VIDEO CENTER OFF

Next, the rest of our test videos, which we will again run in a loop.

STEP 15
VIDEO CENTER attentiongetter LOOP
UNTIL KEY X

STEP 16
Trial Start

STEP 17
LET test_trial = (FROM test_group RANDOM {with max 3 repeats})
VIDEO CENTER test_trial ONCE
UNTIL FINISHED

STEP 18
Trial End
VIDEO CENTER OFF

STEP 19
LOOP STEP 15
UNTIL 7 TIMES

Note that these steps are almost identical to steps 2-7, which made up the training phase. Parallel trial structures like these make it really simple to write protocol files - simply copy and paste the section of STEPs and change step numbers, tags, and other flags as necessary.

Once this loop is completed, the test phase is done, and so is our experiment!

STEP 20
Phase End

Preferential looking

Headturn Preference Paradigm

Habituation

Conditioned Headturn

CRITERIONMET terminating condition

LOOP STEP <number>
UNTIL CRITERIONMET

Below is an example of the basic structure of a habituation protocol.

DEFINE WINDOWSIZE 2
DEFINE WINDOWOVERLAP YES
DEFINE WINDOWTYPE SLIDING
DEFINE BASISCHOSEN LONGEST
DEFINE CRITERIONREDUCTION .65
...
STEP 1
Phase Habituation Start

STEP 2
Trial Start
...

STEP 5
Trial End

STEP 6
LOOP STEP 2
UNTIL CRITERIONMET

STEP 7
Phase End
...

Using the habituation settings above, here is an example of how the basis window and criterion would be calculated by BITTSy across trials.

In this example, note that the target criterion window time (i.e. the maximum time a participant can look during a window and be considered to have met habituation) can change when a new basis window is identified, when BASISCHOSEN is set to LONGEST. The first window in which the child's total looking time is less than the current target criterion time is the window of trials 5+6. After trial 6, when this window is evaluated, CRITERIONMET is true, the loop terminating condition is met, and the loop will no longer repeat. The habituation phase will end, and execution will move on to the next phase of the protocol.

Alternate terminating conditions (did not habituate)

Many times, you want not only a terminating condition for when the participant habituates, but also a point at which the phase would end even if habituation is not reached. For example, you might want to end a phase either when the child habituates, or after 20 trials, whichever comes first.

In this case, you essentially set up two potential endings for the phase:

LOOP STEP <number>
UNTIL CRITERIONMET
UNTIL 19 TIMES

You might decide that you want to exclude particular trials from calculation of habituation. For example, you might wish to exclude any trial that has no looking at all. Or you might want to allow the experimenter to exclude individual trials at the time (say, if they felt the child was distracted by something in the room, such that the trial was not an accurate measure).

The above example would play the file "audiofile" until one of the following occurs:

• You reach the end of the audio file

• A look away is logged that exceeds 2 seconds (when the trial is started only when the experimenter judges the child is already oriented in the active direction, this requires that a look toward the stimulus has already been logged)

• 10 seconds have passed since the trial started and the child has not yet looked at all

• The experimenter presses a designated key (X) to stop the trial

Marking a trial as unsuccessful only excludes the trial from habituation calculations. It does not exclude it from being counted as one of a set number of trials, as in an alternate loop terminating condition. For example, if your phase is set up as

it repeats until either the criterion is met or the loop occurs 20 times - marking a trial as unsuccessful doesn't change the looping.

If you want to replace a no-look trial altogether, you could have another loop that loops the trial until a condition was met. Then the inner loop would do 2 trials if its condition wasn't met the first time, and the outer loop would still go the same number of times, getting you an extra trial for each trial that was not successful.

It is also worth noting that in the syntax above, not only does the trial not count if the child hadn't looked in 10 seconds, but it also ends at that point - that is, it does not continue to play the rest of the sound file. You could have it finish the trial anyway with the statement:

but that would mean that any looks that occurred after 10 second mark would still be ignored from the count of habituation, and yet would presumably influence the child nonetheless. We instead recommend that if you are ignoring a trial for non-looking, that the trial end at whatever point you make that decision.

Here, it ends and is marked as successful if the sound file ends and there were any looks during that time, or if the child looked and then looks away for 2 seconds. It is unsuccessful if the experimenter pressed the X key, or if there weren't any looks at all by the time the audio file ends.

About this protocol

This protocol is based on Newman & Morini (2017), cited below. This study focuses on toddlers' ability to recognize known words when another talker is speaking in the background. The target talker is always female, but the background talker is sometimes male, and sometimes another female talker. When there is a big difference in the fundamental frequency of two voices (as there is for the target female talker and background male talker in this study) adults will readily use this cue to aid in segregating the two speech signals and following the target talker. When the fundamental frequency of the two talkers are similar (as in the female background talker condition), the task is more difficult. This study asks whether toddlers also take advantage of a fundamental frequency cue when it is present, and demonstrate better word recognition when the background talker is male.

Newman, R.S. & Morini, G. (2017). Effect of the relationship between target and masker sex on infants' recognition of speech. Journal of the Acoustical Society of America, 141(2). EL164-169.

This study presents videos showing four pairs of objects. Each object pair is presented on 5 trials, for a total of 20 trials. One of the five for each pair is a baseline trial, in which the speaker talks generically about an object but does not name either one ("Look at that!"). In the other four trials per pair, the target talker names one of the objects. Half of the trials the target object is on the left side of the screen, and half of the trials on the right. All trials, including baseline trials, are presented with the target speaker audio mixed with either a male or female background talker.

Although only 20 test videos are presented to each participant, far more combinations of object pair, target object, target position, and background talker are possible. In this example, we'll demonstrate how to set up this study in several different ways. First, we'll set up the whole protocol with a pre-selected set of 20 videos that satisfy the balancing requirements above, and present all of them in a random order. Next, we'll talk about what we would change in that protocol to present them in a fixed order, and create multiple fixed-order study versions. Lastly, we'll talk about how to use selection from groups and psuedorandomization in BITTSy to select and present appropriate subsets of the possible stimuli for different participants.

Starting the protocol

Starting definitions

The first lines in any protocol are your starting definitions. Here, we will only use one central TV display. We'll name it CENTER.

SIDES ARE {CENTER}
DISPLAYS ARE {CENTER}

Tags

LET truck_ball_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_generic.mp4"
LET horse_bird_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_generic.mp4"
LET cat_dog_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_generic.mp4"
LET blocks_keys_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_generic.mp4"

LET truck_ball_f_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_BALL.mp4"
LET truck_ball_f_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_TRUCK.mp4"
LET truck_ball_m_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_m_BALL.mp4"
LET truck_ball_m_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_m_TRUCK.mp4"
LET blocks_keys_f_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_BLOCKS.mp4"
LET blocks_keys_f_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_KEYS.mp4"
LET blocks_keys_m_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_m_BLOCKS.mp4"
LET blocks_keys_m_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_m_KEYS.mp4"
LET cat_dog_f_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_f_CAT.mp4"
LET cat_dog_f_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_f_DOG.mp4"
LET cat_dog_m_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_CAT.mp4"
LET cat_dog_m_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_DOG.mp4"
LET horse_bird_f_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_f_BIRD.mp4"
LET horse_bird_f_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_f_HORSE.mp4"
LET horse_bird_m_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_BIRD.mp4"
LET horse_bird_m_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_HORSE.mp4"

We have one more tag to define, which is the attention-getter video we'll present before starting each trial.

LET attentiongetter = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\baby.mp4"

Groups

LET trial_videos = {blocks_keys_m_KEYS, horse_bird_m_HORSE, cat_dog_f_CAT, horse_bird_m_BIRD, horse_bird_f_HORSE, truck_ball_m_TRUCK, blocks_keys_f_generic, cat_dog_f_DOG, blocks_keys_f_KEYS, blocks_keys_m_BLOCKS, truck_ball_m_BALL, truck_ball_f_generic, cat_dog_m_generic, cat_dog_m_CAT, truck_ball_f_TRUCK, horse_bird_f_BIRD, horse_bird_m_generic, truck_ball_f_BALL, blocks_keys_f_BLOCKS, cat_dog_m_DOG}

Optional experiment settings

STEPs for execution

STEP 1
Phase Test Start

STEP 2
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 3
VIDEO CENTER OFF

STEP 4
Trial Start

STEP 5
LET vid = (TAKE trial_videos RANDOM)
VIDEO CENTER vid ONCE
UNTIL FINISHED

Now the trial ends. This has to be a new STEP, because UNTIL statements are always the last line of the STEP that contains them, but this happens immediately once the terminating condition (the video ending) is met.

STEP 6
Trial End
VIDEO CENTER OFF

STEP 7
LOOP STEP 2
UNTIL 19 TIMES

Lastly, since we defined a phase start, we'll need to end it.

STEP 8
Phase End

Alternate options for stimuli selection and randomization

What if you don't want trial videos to be presented totally randomly? Or what if you don't want to pre-define a set of videos to present, but rather pull different sets of videos for each participant? Below are some examples of how you might set up your protocol differently for different levels of control over stimuli selection and presentation order.

Fixed orders

You might wish to define a fixed trial order, where every time the protocol is run, participants see the same stimuli in the same order. This requires minimal changes to the example protocol in the previous section.

Tags

Making a fixed-order version of this study would also involve pre-selecting the 20 trial videos that will be shown. You can define just these videos in your tags section, or you can define all of them - it doesn't matter if some are unused in your experiment. Parsing your protocol will take a little longer if you have extra tags defined, but this step is typically done while setting up for a study rather than when the participant is ready, and does not present any issues for running study sessions.

Groups

Crucially for a fixed-order protocol, you will define your trial_videosgroup to list tags in the exact order in which you want them to appear in the study.

STEPs

STEP 5
LET vid = (TAKE trial_videos FIRST)
VIDEO CENTER vid ONCE
UNTIL FINISHED

All of the rest of the protocol would be the same!

If you wished to define multiple fixed-order versions of the study, you could simply save additional copies of the protocol file in which you change the ordering of tags in the definition of trial_videos, or swap in different tags that you have defined. This would be the only change necessary to make the additional versions.

Pseudorandom orders

You might want to not have a pre-defined set of 20 trial videos to use, given that with the different stimulus types and conditions in our study, we actually have 48 possible videos. You might also want to psuedorandomize when trial types are selected - for example, participants may get bored more quickly if they see the same object pair for several trials in a row, so we might want to keep the same pair from being randomly selected too many times back-to-back.

Tags

We'll be defining all the possible video files and tags for this version of the study, because we won't specify in advance which ones the participant will see. First, our baseline trials. We have 4 object pairs, 2 left-right arrangements of each pair, and 2 background talkers, for a total of 16 possible baseline videos.

LET ball_truck_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_f_generic.mp4"
LET ball_truck_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_m_generic.mp4"
LET truck_ball_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_generic.mp4"
LET truck_ball_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_m_generic.mp4"
LET horse_bird_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_f_generic.mp4"
LET horse_bird_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_generic.mp4"
LET bird_horse_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_f_generic.mp4"
LET bird_horse_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_m_generic.mp4"
LET cat_dog_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_f_generic.mp4"
LET cat_dog_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_generic.mp4"
LET dog_cat_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_f_generic.mp4"
LET dog_cat_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_m_generic.mp4"
LET blocks_keys_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_generic.mp4"
LET blocks_keys_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_m_generic.mp4"
LET keys_blocks_f_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_f_generic.mp4"
LET keys_blocks_m_generic = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_m_generic.mp4"

Now our trial videos. We have even more of these, because now the target word said by the main talker could be either of the two objects - a total of 32 videos & tags.

LET ball_truck_f_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_f_BALL.mp4"
LET ball_truck_f_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_f_TRUCK.mp4"
LET ball_truck_m_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_m_BALL.mp4"
LET ball_truck_m_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\ball_truck_m_TRUCK.mp4"
LET truck_ball_f_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_BALL.mp4"
LET truck_ball_f_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_f_TRUCK.mp4"
LET truck_ball_m_BALL = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_m_BALL.mp4"
LET truck_ball_m_TRUCK = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\truck_ball_m_TRUCK.mp4"
LET blocks_keys_f_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_BLOCKS.mp4"
LET blocks_keys_f_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_f_KEYS.mp4"
LET blocks_keys_m_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_m_BLOCKS.mp4"
LET blocks_keys_m_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\blocks_keys_m_KEYS.mp4"
LET keys_blocks_f_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_f_BLOCKS.mp4"
LET keys_blocks_f_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_f_KEYS.mp4"
LET keys_blocks_m_BLOCKS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_m_BLOCKS.mp4"
LET keys_blocks_m_KEYS = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\keys_blocks_m_KEYS.mp4"
LET cat_dog_f_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_f_CAT.mp4"
LET cat_dog_f_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_f_DOG.mp4"
LET cat_dog_m_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_CAT.mp4"
LET cat_dog_m_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\cat_dog_m_DOG.mp4"
LET dog_cat_f_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_f_CAT.mp4"
LET dog_cat_f_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_f_DOG.mp4"
LET dog_cat_m_CAT = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_m_CAT.mp4"
LET dog_cat_m_DOG = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\dog_cat_m_DOG.mp4"
LET bird_horse_f_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_f_BIRD.mp4"
LET bird_horse_f_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_f_HORSE.mp4"
LET bird_horse_m_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_m_BIRD.mp4"
LET bird_horse_m_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\bird_horse_m_HORSE.mp4"
LET horse_bird_f_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_f_BIRD.mp4"
LET horse_bird_f_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_f_HORSE.mp4"
LET horse_bird_m_BIRD = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_BIRD.mp4"
LET horse_bird_m_HORSE = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\horse_bird_m_HORSE.mp4"

The last tag to define is our attention-getter video.

LET attentiongetter = "C:\Users\ldev\Desktop\BITTSy\ToddlerBGGender\baby.mp4"

Groups

Defining the groups in this protocol is the really critical step for allowing us to control how stimuli are later balanced - how many of each target pair we show, how many times the named object is on the left or the right, how many trials have a male background talker vs. female.

We will construct a nested structure of groups. It is often helpful to work backwards and plan your group structure from the top down - that is, from the highest-level group that you will select from first in your protocol, to the lowest-level group that directly contains the tags referencing your stimuli files. We'll end up with 3 levels of groups for this protocol.

Your highest-level group's components should be defined around the characteristic that you want the most control over for pseudorandomization. Here, we'll make that be our object pairs. Our highest-level group, trial_videos, will contain groups for each of the four object pairs.

LET trial_videos = {ball-truck_ALL, bird-horse_ALL, blocks-keys_ALL, cat-dog_ALL}

Now let's define one of these groups for an object pair. We're going to have five trials per object pair. One of these has to be a baseline trial. For the remaining four, we'll stipulate that they are:

1. a video with a female background talker where the object named by the target talker is on the right

2. a video with a female background talker where the object named by the target talker is on the left

3. a video with a male background talker where the object named by the target talker is on the right

4. a video with a male background talker where the object named by the target talker is on the left

LET ball-truck_ALL = {ball-truck_baseline, ball-truck_f_right, ball-truck_f_left, ball-truck_m_right, ball-truck_m_left}

Now we'll define these component groups, which will contain our video tags. First, the baseline group. There were four baseline videos for each object pair.

LET ball-truck_baseline = {ball_truck_f_generic, ball_truck_m_generic, truck_ball_f_generic, truck_ball_m_generic}

For the other four groups, we defined two videos that match each trial type.

LET ball-truck_f_right = {ball_truck_f_TRUCK, truck_ball_f_BALL}
LET ball-truck_f_left = {ball_truck_f_BALL, truck_ball_f_TRUCK}
LET ball-truck_m_right = {ball_truck_m_TRUCK, truck_ball_m_BALL}
LET ball-truck_m_left = {ball_truck_m_BALL, truck_ball_m_TRUCK}

We'll define the nested group structure for our other object pairs the same way.

LET ball-truck_baseline = {ball_truck_f_generic, ball_truck_m_generic, truck_ball_f_generic, truck_ball_m_generic}
LET ball-truck_f_right = {ball_truck_f_TRUCK, truck_ball_f_BALL}
LET ball-truck_f_left = {ball_truck_f_BALL, truck_ball_f_TRUCK}
LET ball-truck_m_right = {ball_truck_m_TRUCK, truck_ball_m_BALL}
LET ball-truck_m_left = {ball_truck_m_BALL, truck_ball_m_TRUCK}

LET bird-horse_baseline = {bird_horse_f_generic, bird_horse_m_generic, horse_bird_f_generic, horse_bird_m_generic}
LET bird-horse_f_right = {bird_horse_f_horse, horse_bird_f_bird}
LET bird-horse_f_left = {bird_horse_f_bird, horse_bird_f_horse}
LET bird-horse_m_right = {bird_horse_m_horse, horse_bird_m_bird}
LET bird-horse_m_left = {bird_horse_m_bird, horse_bird_m_horse}

LET blocks-keys_baseline = {blocks_keys_f_generic, blocks_keys_m_generic, keys_blocks_f_generic, keys_blocks_m_generic}
LET blocks-keys_f_right = {blocks_keys_f_keys, keys_blocks_f_blocks}
LET blocks-keys_f_left = {blocks_keys_f_blocks, keys_blocks_f_keys}
LET blocks-keys_m_right = {blocks_keys_m_keys, keys_blocks_m_blocks}
LET blocks-keys_m_left = {blocks_keys_m_blocks, keys_blocks_m_keys}

LET cat-dog_baseline = {cat_dog_f_generic, cat_dog_m_generic, dog_cat_f_generic, dog_cat_m_generic}
LET cat-dog_f_right = {cat_dog_f_dog, dog_cat_f_cat}
LET cat-dog_f_left = {cat_dog_f_cat, dog_cat_f_dog}
LET cat-dog_m_right = {cat_dog_m_dog, dog_cat_m_cat}
LET cat-dog_m_left = {cat_dog_m_cat, dog_cat_m_dog}

LET ball-truck_ALL = {ball-truck_baseline, ball-truck_f_right, ball-truck_f_left, ball-truck_m_right, ball-truck_m_left}
LET bird-horse_ALL = {bird-horse_baseline, bird-horse_f_right, bird-horse_f_left, bird-horse_m_right, bird-horse_m_left}
LET blocks-keys_ALL = {blocks-keys_baseline, blocks-keys_f_right, blocks-keys_f_left, blocks-keys_m_right, blocks-keys_m_left}
LET cat-dog_ALL = {cat-dog_baseline, cat-dog_f_right, cat-dog_f_left, cat-dog_m_right, cat-dog_m_left}

LET trial_videos = {ball-truck_ALL, bird-horse_ALL, blocks-keys_ALL, cat-dog_ALL}

STEPs

Now that we've defined our group structure, implementing the stimulus selection is really easy. Our protocol starts off just like the original version with playing the attention-getter video before every trial.

STEP 1
Phase Test Start

STEP 2
VIDEO CENTER attentiongetter LOOP
UNTIL KEY C

STEP 3
VIDEO CENTER OFF

In our original setup with the pre-determined stimulus set, we then started a trial, picked a video, and displayed it. In this one, we have multiple selection steps, and BITTSy takes a (very, very small) bit of time to execute each one. Given that we have several, we might prefer to place these before our trial starts, just to ensure that there's never a gap between when BITTSy marks the beginning of a trial and when the video actually starts playing. (If you are not relying on BITTSy logs for trial timing and instead use cues in your participant video, such as lighting changes in the room or an image of your display in a mirror, this doesn't matter at all!)

STEP 4
LET pair = (FROM trial_videos RANDOM {with max 4 repeats, with max 2 repeats in succession})
LET type = (TAKE pair RANDOM)
LET vid = (FROM type RANDOM)

Lastly, we need to pick a particular video tag from type. We will do this randomly. It doesn't matter whether we define this selection with FROM or TAKE because, per the previous selection where we chose type, we can't get this same subgroup again later.

Now that we have the trial video we want to display, we can run a trial.

STEP 5
Trial Start
VIDEO CENTER vid ONCE
UNTIL FINISHED

STEP 6
Trial End
VIDEO CENTER OFF

Just like in the original example version of this protocol, we'll loop over the steps that define an attention-getter + a trial to display a total of 20 trials. Then, our experiment is done.

STEP 7
LOOP STEP 2
UNTIL 19 TIMES

STEP 8
Phase End

About this protocol

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:

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.

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").

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

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

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.

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

Optional experiment settings

STEPS for execution