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

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.

Some infant testing procedures have a set time per trial (e.g., play this stimulus for 4 seconds, or play this sound file until it ends); for others, trial lengths depend on the child's looking behavior, requiring that the experimenter code behavior while the experiment is running. BITTSy allows individual stimuli to either , or to play until an event occurs (such as ), or for a of these (e.g., until a child looks away for X seconds, or until the file ends, whichever comes first). It also allows different trials to continue to occur for a , or is reached (e.g., in habituation-based studies, or in training studies). Thus, an experiment might be set up to continue presenting the stimulus within a given trial until the child looks away for 2 seconds, but then to continue playing trials until some cumulative amount of looking has occurred. All of these timing constraints can be set up as part of the protocol file.

BITTSy runs a number of standard infant/toddler testing paradigms, such as the Headturn Preference Procedure, Preferential Looking Paradigm, and Visual Fixation Procedure. It allows researchers to use either lights or videos as attention-getters and to present stimuli on any given trial that are either audio-only, visual only, or audio-visual. Experimenters can fully determine which stimuli to present on which trials, whether trials are repeated, and whether stimuli are presented in a fixed order, randomized within blocks, or fully randomized. They can set the relative timing of all presentation events, and set up multiple phases within an experiment. Experimenters can specify whether individual stimuli, trials, and experimental phases continue for fixed amounts of time or continue until the child reaches a particular looking/listening criterion. Investigators can code infant looking during testing, or off-line from recordings.

BITTSy creates a raw ("low-level") log file of all events that occur within a session. However, it also includes a separate analysis module to summarize the data in a more usable fashion based on standard analysis requirements. This dual file-function allows an experimenter to go back and reanalyze different aspects of the data at a later time, an option that is not available in most current infant systems.

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

• HPP: Headturn Preference Procedure

• HVFP: Visual Fixation Procedure / Habituation

• PLP: Preferential Looking Procedure / Looking while Listening

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.

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 do not recommend using on-board sound from televisions with BITTSy (see here for more info). Therefore, when selecting displays, it is not necessary to consider sound quality.

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.

We used two TOGUARD WR943 10.1” screens for the side locations, but any smaller television or computer monitor would work as well.

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.

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.

BITTSy works on the basis of protocol files. A protocol file is basically the instruction set for that particular experiment or experimental session. The protocol file instructs the program on what stimuli to play, when to play them, how many trials should occur, how they should be randomized, etc.

A protocol file can be made up of multiple phases, or sub-sections; each phase can be made up of multiple individual trials. Generally, you would want to create different phases if you were changing stimulus sets (e.g., a training phase vs. a testing phase), or changing paradigm (e.g., a habituation phase followed by a preferential looking phase). Each phase can essentially work akin to an entirely separate experiment.

The trials within a phase can be entirely distinct, if each trial is set up as a single, specified, set of events, but typically trials share similarity within one another (e.g. 12 trials that each present one of a set of stimuli in random order, but have the same timing structure). BITTSy is entirely flexible with regards to this, however. A protocol file could list every event individually, and be specific for a single participant - but it is far more efficient to create protocol files that select from a set of items and repeat types of trials where the same trial structure is reused.

The flexibility that BITTSy provides does come with a bit of a cost - you need to specify a lot more detail than would be needed in a computer program that restricted you to fewer options. As a result, protocol files can get rather long, and are essentially similar in many ways to programming. However, once a template has been created for an experiment/paradigm it is very easy to modify it by swapping out the file names, reordering them in groups, changing the restrictions on action clauses, etc. We thus provide some sample protocol files, and would recommend creating new ones by making adjustments to existing protocol files rather than by starting from scratch each time. Moreover, we have worked to make the protocol files, and the commands embedded within them, highly intuitive - even a novice student researcher should be able to read a protocol file and understand what is happening at each point in the experiment.

To create and edit protocol files, we recommend using Notepad ++. This application includes a side bar that numbers each line of the protocol, making it easier to go back and make changes based on any error messages that BITTSy may present.

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

In BITTSy, the habituation criteria can be based on a percentage decrease from initial looking (e.g., the first 3 trials), or from peak looking (the 3 trials with longest average looking). You can also set the amount of decrease in looking (e.g., 50%, 60%) and the number of trials over which looking is averaged.

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.

See the habituation section for more information about setting up visual fixation/habituation studies in BITTSy.

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.

Creating conditioned headturn studies in BITTSy was made possible with the addition of the JUMP command in version 1.5. Due to its later introduction, implementing conditioned headturn paradigm is currently a bit "clunkier" than the other main paradigms BITTSy was designed to run, and the process of developing these protocols is typically more complex. While BITTSy can execute the typical trial and phase structures of conditioned headturn, there are some types of phase progression logic used in prior studies that are difficult to replicate exactly in BITTSy. However, similar to headturn preference procedure, the use of conditioned headturn has been limited by the unavailability of a standard system capable of running these procedures. The ability of BITTSy to run these paradigms provides an easy way for researchers to begin using this paradigm. We hope that BITTSy will allow more labs to adopt and adapt this paradigm for their research.

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.

BITTSy is set up with default keys for coding (see later section on coding for more details), but these can be altered to fit the preferences of the lab. (However, we generally recommend that the same experiment use the same coding keys for different participants.)

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.

If you would instead like to assign your own keys, use this syntax within your optional experimental settings section (see linked page for more info).

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

BITTSy creates a of all events that occur within a session. This means that everything is logged, allowing full access to data. However, these detailed files are not particularly user-friendly. A takes information from the log file and summarizes it in a manner more useful to the experimenter. We have tried to anticipate common summary information that might be desired, but additional summary analyses can be created from the detailed log file at any time.

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

Events can be specified to occur in a set order. However, there are also a number of aspects that can be selected randomly. These include the side of occurrence for an event (left vs. right) and the particular stimulus from a set. can occur WITH or WITHOUT replacement - that is, BITTSy will keep track of which items it has already selected, and can avoid reusing items until all have already been selected (without replacement), or can just pick entirely randomly each time regardless of what has already been selected (with replacement). You can also on the number of times the same thing can be re-selected (e.g., pick a side randomly, but don't present to the same side more than X times in a row).

Stimuli can also be arranged in , with randomization occurring within sets. As an example, you could have pictures of animals which include cats and dogs, with multiple examples of each, and could tell BITTSy to select one of the two animal types randomly, then randomly order the presentations of all the different examples within that animal type before moving on to the other animal type.

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.

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.

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.

We purchased the ENTTEC DMXUSB PRO (part number 70304).

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.

There is a cheaper option from Enttec that is a more pared-down DMX controller, the ENTTEC Open DMX USB (part number 70303). It has a USB connection and DMX OUT (the one you need!). It was not available when we purchased the Pro unit, but it has all the capabilities that are needed for controlling lights in BITTSy and should function identically.

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.

We used the Elation DP-415.

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.

The same company also made a new item, the CYBER PAK, which is the replacement unit - we have not tried it, but this or any other DMX dimmer/switch pack should work similarly, since DMX is a standard.

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.

3. Color. For headturn preference, where the center light is consistently used between trials and the two side lights during trials, it is nice to have the center light cover be a different color than the side lights' covers. This helps experimenters identify which light is active even more easily during testing. Our center light has a red cover, and our side lights' covers are yellow-orange.

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.

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.

Sometimes, you may wish to build a protocol file from scratch. But other times, particularly if the study you are building is fairly prototypical example of a common behavioral paradigm, you may be able to adapt an existing protocol file to meet your needs - and this is certainly easier! See our and for sample protocols of headturn preference, preferential looking, and habituation studies.

Audio and displays

Follow installation instructions for your selected speakers and displays.

For BITTSy to display image and video stimuli, your system's display settings should be set to Extend mode. .

There are several audio issues that can be identified during setup that can cause problems for experiments in BITTSy (or any other experimental software) later. See for more info.

Lights

1. Connect the (such as ENTTEC DMX USB PRO) to the computer tower. Both ends should be USB ports (albeit different types).

2. Connect your (such as DP-415 unit) to a power source.

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.

4. Connect dimmer pack to the lights. If you wish to control each light individually (as in a headturn preference setup with a left, center, and right light), ensure that they are plugged under separate numbered channels. The numbering of the channels on your dimmer pack will generally match with the device IDs used by BITTSy, but this will be confirmed later when you run the !

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.

6. Check for necessary firmware/drivers for your USB-DMX interface box. If you purchased from ENTTEC, see the Downloads section at the bottom of the product page ( for the ENTTEC DMX USB Pro); download and install both the Win D2XX driver and the recommended firmware.

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

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

When creating your stimulus files, keep in mind of your display(s) on which they will be shown. BITTSy will display stimuli at full size, and could cut off an image or video that is sized too large. Visual stimuli that are smaller than the screen resolution will be displayed centered, with the for that protocol shown behind it.

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.

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:

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

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.

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:

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.

Below are descriptions of experimental settings that can be changed to suit a particular study or paradigm. Within a protocol, these lines can be added anytime after the and before the first STEP.

Key assignments

Transitions between STEPs, trials, and phases can be controlled by participant looking time, recorded by an experimenter via . To live-code an experiment or have looking-controlled timing, the keys you will use for coding need to be assigned to the looking direction so that they can be matched to stimuli being presented on that side.

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:

where <side> is any side named in the , or AWAY, and <key> is any alphanumeric key or arrow key. (Arrow keys are denoted by the codes UP, DOWN, LEFT, and RIGHT.)

Below are several examples.

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.

For example,

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.

Habituation-specific settings

Download BITTSy

to download the latest version of BITTSy (note the last modified date and version number in the file name).

When you are first starting with BITTSy, you will also need to download the Setup zip file, located on the same download page (see for how to use the setup protocol).

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.

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.

Dynamic tags are explained further in the section on randomization and selection from groups. But they are another type of tag that, once defined, work in the same way as the tags discussed thus far. They can reference a particular stimulus file or they can reference a group, and they can be used in selection statements or action statements in the same way as static tags.

Steps

BITTSy runs with a series of STEPS. The steps run in order, and everything that occurs in the experiment itself is part of a step. Steps allow you to LOOP back, which is how you repeat sections of execution (such as trials) - and thus steps are a fundamental way in which the program is structured.

The first line that defines a STEP marks an important division in the protocol file. Everything in a protocol file discussed thus far, with the exception of dynamic tags - starting definitions, optional settings, file path definitions for tags, group definitions - must all precede the first STEP. All of these are fully validated and processed by BITTSy prior to the start of an experiment. Once the experimenter clicks to run a protocol, the portion of the protocol file being executed is what follows STEP 1.

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.

STEPs should be numbered in ascending order with no duplicates or missing values. Misnumbering steps will not necessarily result in any problems executing your protocol. But when loops are involved, there may be serious issues jumping back to an indicated STEP and executing intervening steps if the LOOP references steps that have been misnumbered.

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

STEPs can optionally end in step terminating conditions, which specify conditions that must be met before execution can proceed from one STEP to the next STEP. These are the UNTIL statements in the example above. When thinking about how to divide the progression of your experiment into STEPs, the most important thing to consider will be the necessity for these terminating conditions, and which actions in your experiment need to occur before you wait for one to be met. (How to structure STEPs and protocols will become clearer as you learn more in the upcoming sections, and look through example protocols.)

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.

When reporting looking time across trials, BITTSy will number trials within each phase, and restart numbering when a new phase is defined.

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

Marking divisions between phases is helpful for analyses of looking time through BITTSy's reporting module: phases are listed separately in these reports. Trials can always be looked at individually, but trials within the same phase can also be summed/averaged across automatically in reports. Thus, phase definitions should be placed to demarcate which trials can be analyzed together.

In some cases, the placement of phase definitions can impact the execution of protocols. For example, cumulative looking time can be calculated within the current phase, and exclude other trials previous to that phase. In habituation, phase definitions allow BITTSy to "know" to reject windows containing trials from two different phases (i.e. not including a pre-test trial as part of a basis window, as the pre-test should be considered completely separately from habituation phase trials).

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

File paths for stimulus files used in BITTSy cannot contain any whitespace characters. (This will cause a validation error in BITTSy.) If any of the folder names within your filepath contain spaces, you will need to rename them within Windows File Explorer. If your files are stored under a particular user account that contains a space, you will also need to change the username to not include a space.

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}

LINKED tags allow you to refer to their paired components by the same tag name (dog in the example above). For more, see the section on using LINKED tags in action statements.

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)

The first two types of tags - tags denoting particular stimulus files, and tags that are given to name groups of other tags - are defined near the start of your protocol, anywhere after the starting definitions and before your first STEP statement. See the following pages for more information on these tags.

Groups are tags that refer to a set of other tags. The tags within the group could refer directly to particular stimulus files, or they could be groups themselves.

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.

In this example, dog, cat, snake, and turtle refer directly to files (the tag type covered in the previous section). The tags mammals, reptiles, and animals are all groups - but while the members of mammals and reptiles are tags referring to files, animals is a group of other groups.

Groups allow for random selection from within a set of tags, which can be used iteratively to select subsets of stimuli before selecting a particular stimulus from the final subset. Ultimately, the purpose will be to present a selected stimulus using an action statement. In order to select through a consistent number of steps, no matter which tags from within groups are chosen, the tags that are contained in a single group should be at the same level in the tag hierarchy. For example, if we wanted to make a group that was the set of the above animals that have legs, we could define:

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 side names that can be used in groups should be previously defined in the starting SIDES definition.

Many experiments require selecting a particular stimulus from a group of stimuli and presenting it. Once a is defined, tags that denote particular stimuli can be chosen in BITTSy, with or without replacement, either in the order in which they are listed in the group or with randomization. This is done with choose statements.

Choose statements can occur on their own, but they are often employed within , sections of steps that repeat until a specific condition is met. For example, a particular STEP could select and display an image from a group, and a loop could repeat that STEP until all of the images have been chosen and displayed. After covering the basics of choose statements and loops individually, more about how they work together can be seen in the .

Choose statements and dynamic tags

Remember ? Unlike other tags, they are not defined at the start of a protocol. Rather, they get defined through choose statements, within the steps of your protocol, and refer to the result of that choose statement on its most recent execution.

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

The restrictions on valid dynamic tag names are the same as for other . Unlike static tags that directly denote files or groups, there is no restriction on defining the same dynamic tag name twice - indeed, this is extremely common, as you are often creating and overwriting dynamic tags via executing a choose statement within a . However, they must not have the same name as any static tag.

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.

You can think of dynamic tags like arrows. If the choose statement selects beagle from the group, dog points to beagle, and in the subsequent to display the image, BITTSy follows the arrow back from dog to beagle to the actual file on your computer it will access and display.

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.

Often, dynamic tags are used within a . Loops repeatedly execute a set of STEPs within a protocol. When a dynamic tag and choose statement are defined within a loop, the choose statement is executed each time the loop runs, and the assignment of the dynamic tag changes each time.

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.

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)

See the other pages in this section for specifics on how to set habituation criteria, reach (or not reach) habituation and proceed to another phase of the experiment, or exclude particular trials from habituation calculations that do not meet desired criteria.

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

Sides that are used in IMAGE action statements should come from the SIDES starting definition and should be matched to a display in the DISPLAYS starting definition.

Videos

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

VIDEO CENTER checkerboard LOOP
VIDEO CENTER OFF

Sides that are used in VIDEO action statements should come from the SIDES starting definition and should be matched to a display in the DISPLAYS starting definition. The audio component of the video will play through a correspondingly-named audio channel, if available (see explanation for both stereo and multichannel audio systems below).

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

To make use of more than two speakers on a multichannel audio system, your protocols will require an AUDIO starting definition in order to provide names for the available audio channels. Any of these names can then be used in the AUDIO action statement format.

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 tags are defined earlier in the protocol, and consist of 2 or 3 member tags of different types (image, audio, or video).

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.

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>

With a KEY terminating condition, execution waits at the current step until the experimenter presses the specified key. For a protocol using live-coding, these could be used to time the start of steps according to where the experimenter judges that the participant is looking - in this case, you should specify the same keys that you have assigned to sides for live coding. You may also wish to use keypresses to progress the experiment without tying it to participants' looking behavior. In this case, you can use any valid unassigned 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

In this case, the terminating condition would be waiting for a look to be recorded by the experimenter that was to the left (as defined by the key assignments in the protocol), where the dynamic tag trialaudio is being presented, that lasts for at least 5 seconds before the experimenter indicates the participant has looked in another direction (by pressing a key that has not been assigned to LEFT).

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.

Importantly, BITTSy's timer on looks starts when the tag begins to be active/displayed, so if the participant starts in a state of looking away from the tag, they could meet this terminating condition without ever having a look that was in the direction of the tag. If you would like to require this (a look but then a look away), you should set up the preceding step such that they must start in the correct direction (as is typically the case in HPP studies).

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

Just like step terminating conditions, loop terminating conditions can be combined together for more complex end conditions. They can be joined by an AND, such that both conditions must be met:

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

This loop terminating condition is met when the time a participant spends looking toward a tag, totaled across all its presentations in a given phase of the experiment, meets the given threshold.

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

The example above is a common one used in HPP studies, where two training stimuli alternate until both reach a fixed criterion. But this has at times been criticized because if one of the two music files reaches criterion and the other does not, it will continue to loop - and the loop could mean that it keeps playing the stimulus that had already reached criterion, rather than the one that still needed to do so. This could result in OVER familiarizing one of the two stimuli (or habituating to it) before the other one reaches criterion. This can be solved with JUMP statements - see the example here for a solution to this exact problem.

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

See the section on habituation for more about the CRITERIONMET condition.

All habituation settings are defined in the same section of the protocol as such as key assignments. These settings are designed to allow experimenters to define and control habituation experiments in BITTSy similarly to established habituation procedures.

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

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

This can be done, and is part of the used within a trial. You have already learned how to denote end conditions that are "successful" and should let the trial be counted for habituation calculations - these are simply UNTIL statements. "Unsuccessful" end conditions are the same kinds - just with an UNSUCCESSFUL flag.

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

As with other , these conditions are treated as "whichever comes first". So, if the 3rd or 4th condition were met first, the trial would be unsuccessful. The trial would end at that point, and would not be counted as a trial for the purposes of habituation calculations, which depend on successful trials. (More precisely, this means that any window containing this trial would not be evaluated as either a potential basis window or criterion window.) If condition 1 or 2 were met instead, the trial would then end, and it would be counted.

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.

This section features walkthroughs of examples of some common study paradigms. Check the page for the full protocols and stimuli sets if you would like to try running these example protocols or adapt them for your own studies.

Preferential looking

Headturn Preference Paradigm

Habituation

Conditioned Headturn

CRITERIONMET terminating condition

LOOP STEP <number>
UNTIL CRITERIONMET

Habituation phases are generally set up as a trial (or set of trials) occurring within a loop. CRITERIONMET is a special loop terminating condition for habituation that is based on looking-time reduction from a basis window. How the basis window is chosen, and what reduction in looking time it takes to consider the child to be habituated, are defined at the beginning of a protocol as habituation criteria. The CRITERIONMET terminating condition, whenever it is evaluated, checks whether these habituation conditions have been satisfied.

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.

It is important to note that, like all loop terminating conditions, CRITERIONMET is only checked when the loop step is reached - that is, after each time the contents of the loop have been fully executed (see loop terminating conditions for an expanded explanation.) This means that if the loop contained two trial starts and trial ends, CRITERIONMET would only be evaluated after even-numbered trials. This does not prevent BITTSy from evaluating and identifying criterion windows based on the habituation settings in the protocol. But it does mean, in this case, if a criterion window was identified that ended with an odd-numbered trial, one additional habituation trial would be run before the loop would end. For this reason, it is generally recommended to only define one trial within a habituation loop, and if stimuli vary across trials, to define their cycling via selection from groups. (See the example protocols page for examples of setting up simple and more complex habituation phases.)

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

In a loop clause, if you have two different UNTIL statements, with a carriage return between them, they are treated as if they are linked by an OR condition (see this section for all available options). This would mean it would end either if the criterion was met or if it had already looped through 19 times (after the first one, so UNTIL 19 TIMES means there would be 20 times total).

Whichever terminating condition is met first, execution will progress to the next step: it is not possible to skip to a different step or phase based on which condition is met. Generally, this means that the post-habituation test phase of a typical habituation experiment would be shown to all participants, whether or not they habituated. When generating a habituation report from the event log of a test session, it is marked whether the participant habituated (i.e. met the CRITERIONMET condition rather than the alternate one) so that participants who did not habituate can be recorded as such, and excluded from analyses of looking time in the test phase.

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

The opening section of a protocol, before any STEPs are defined, typically takes up the bulk of your protocol file. This is especially the case in , in which there are often large sets of video stimuli to define as tags and arrange in groups. While this part may seem to take a while, by the time you do this, you're almost done!

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.

Tags

Before creating this protocol, we pre-selected 20 videos that fit balancing requirements for the study, such as having an equal number of trials with the female background talker as with the male background talker. We happen to have more possible videos for this study, but a study with fewer factors or more trials, that displays all stimuli to every participant, could be constructed exactly like this. (.)

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

Groups

Optional experiment settings

STEPs for execution

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.

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

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

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.

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.

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

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.

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

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.

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

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

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.

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!)

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.

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.

About this protocol

This protocol is based on a commonly-given example of rather than a particular study. The question is whether young infants can recognize that objects of the same kind but with their own unique appearances all belong to the same category. Can infants recognize a pattern in the images that are being presented - that they are all cats, or that they are all dogs? And when an image is presented that does not belong to the category, do they notice that it is different?

As infants recognize the pattern or "rule" in the habituation phase (that all the images are the same kind of animal) we expect them to start to pay less attention to the individual images. This decrement in looking time across trials is the principle of habituation. But what really demonstrates whether they have learned the pattern is whether they show an increase in looking time when presented with something outside of the category, relative to another novel example of the trained category.

Here, we'll habituate infants to either instances of cats or instances of dogs. Later, to both groups, we'll present one new image each of a dog and a cat. We might think that breeds of dogs are more visually dissimilar from each other than breeds of cats, and we might expect that infants who are habituated to cats will have greater success in detecting which test phase image doesn't belong to their learned category. They may be more likely to recognize that the dog presented in the test phase is something different and more interesting than another cat image, while infants who are habituated to dogs may be less likely to recognize the cat in the test phase as particularly novel.

At the very beginning and very end of our experiment, we'll have pre-test and post-test trials. These help us see whether the participant is as actively engaged at the end of the experiment as they were at the beginning. It lets us differentiate children who didn't recognize the category switch but were still paying attention in general (looking longer at the post-test stimulus, even if they didn't look long during the test phase) from children who were simply bored or inattentive (looking very little at the post-test stimulus).

Starting the protocol

Starting definitions

We'll begin with our starting definitions. In this protocol, we'll only use one central display, and code looks towards/away that monitor.

Tags

We have a lot of tags to define for this protocol, because we'll be using a lot of image files. We'll have a maximum of twenty images displayed of either cats or dogs in the habituation phase of the experiment, plus one of each for test, and two unrelated images for a pre-test and post-test (these should be consistently really interesting to infants - but as a placeholder, we'll use turtles). We'll also show an attention-getter video in between trials.

This file definition section is a very large portion of our protocol. We've abbreviated it below.

Groups

We'll have two conditions that participants are randomly assigned to - they will either be habituated to the group cats, or the group dogs. After they are habituated to that group, they will see the images dog_test and cat_test. In this protocol, we'll have infants always see the image that wasn't the category they were habituated to as the first image of the test phase, then the other example of the habituated category on their second test trial. Let's create groups that list what they'll see in each of these possible conditions, in order of presentation.

Lastly, so that we can randomly select a condition for the participant at the start of a study session, we'll make a group that contains both.

Experiment settings

STEPS for execution

Pre-test

Now, our experiment begins. First, we'll have a pre-test phase, where we'll show something unrelated to our habituation and test images. Here we're using two similar images for pre- and post-test and will select them randomly from the prepost group, but it is common to use the same image for both.

Like all other trials in our study, we'll play an attention-getter video beforehand, and only start the trial once the experimenter indicates the child is looking at the screen. Then, the experimenter will continue to code the child's looks toward and away from the image being displayed. If the child has a single look away from the screen that lasts at least 2 seconds, or if the image has been displayed for a maximum length of 20 seconds, the trial will end.

Habituation

Next comes our habituation phase. First, we will need to assign this participant to one of our study conditions - habituating to cats, or habituating to dogs. We'll choose this randomly.

Recall that this condition we pick (either habitcats or habitdogs) contains three tags:

1. the group of tags to display in habituation

2. a tag referring to the test item from the novel category

3. a tag referring to the test item from the familiarized category

Now, we'll display another attention-getter and a habituation trial.

Test phase

Now for our test phase. We'll start it off, and keep having attention-getter videos in between trials.

There are two test trials - so let's loop to repeat this section to play the second one.

Post-test

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.

This study was not originally run in BITTSy, and it used four fixed-order experiment files to control condition assignment and trial order rather than the randomization set up in this example protocol. However, this kind of multi-phase study, with multiple conditions and restrictions on stimulus presentation order in each phase, is a great example of a more complex preferential looking study (see for a simpler case). Below is a walk-through of how you could recreate its structure in BITTSy.

Starting the protocol

Starting definitions

As in any protocol, first come the :

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

Next, we're going to set up all the .

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.

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

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.

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

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.

Groups

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.

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.

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

Now we're ready to define our groups of groups - each whole order, from training to 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.

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

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.

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

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

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.

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.

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

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!

About this protocol

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

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

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

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

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

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

Starting the protocol

Starting definitions

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

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

A note about HPP and defining LEFT and RIGHT

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

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

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

Tags

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

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

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

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

Groups

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

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

LET trainingmusic = {trainingmusic1, trainingmusic2}

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

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

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

LET testaudio = {testblock1, testblock2, testblock3}

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

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

Optional experiment settings

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

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

STEPS for execution

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

Familiarization

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

STEP 1
Phase Train Start

STEP 2
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 3
LIGHT CENTER OFF

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

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

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

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

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

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

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

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

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

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

STEP 8
Phase End

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

Test

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

STEP 9
Phase Test Start

STEP 10
LET block = (TAKE testaudio FIRST)

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

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

STEP 11
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 12
LIGHT CENTER OFF

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

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

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

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

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

STEP 16
LOOP STEP 11
UNTIL 3 TIMES

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

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

STEP 17
LOOP STEP 10
UNTIL 2 TIMES

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

STEP 18
Phase End

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

See the resources page for a copy of this protocol.

About this protocol

This protocol is based on Experiment 3 of the classic Werker et al. (1998) study cited below. Infants are habituated to a single word-object pair. Later, they are presented with four test items: familiar object with familiar word, familiar object with novel word, novel object with familiar word, and novel object with novel word. Pre-test and post-test trials, consisting of a novel object and word that do not appear in any other trials, are also included.

Werker, J. F., Cohen, L. B., Lloyd, V. L., Casasola, M., & Stager, C. L. (1998). Acquisition of word–object associations by 14-month-old infants. Developmental psychology, 34(6), 1289.

Starting the protocol

Starting definitions

This protocol will use one central display and a light positioned directly below the display. These would be our minimal starting definitions:

SIDES ARE {CENTER}
DISPLAYS ARE {CENTER}
LIGHTS ARE {CENTER}

However, if you have more lights connected in your system (e.g. for headturn preference procedure) and will be leaving them all connected during testing, you may need to define more lights so that you can identify which one should be CENTER.

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

Tags

Now we'll define our tags that reference files. We have three audio files and three video files - two of each for use in habituation/test trials, and one of each reserved for pre-test and post-test.

We could define these with LET statements. But because these will always be paired, it is convenient to use TYPEDLET. This will allow us to define all of our possible word-object pairings and randomly select a pair for presentation, rather than independently selecting audio and video, and having less control over which appear together.

Our videos, which we'll call round, green, and blue, show toys being rotated by a hand on a black background. Our audio files consist of infant-directed repetitions of a nonword: deeb, geff, or mip.

TYPEDLET audio deeb = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\deeb.wav"
TYPEDLET audio geff = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\geff.wav"
TYPEDLET audio mip = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\mip.wav"
TYPEDLET video blue = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\blue.mp4"
TYPEDLET video green = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\green.mp4"
TYPEDLET video round = "C:\Users\ldev\Desktop\BITTSy\HabitExample\stim\round.mp4"

Having defined these tags with TYPEDLET, we can use LINKED to define tags that pair them up appropriately. The tags mip and round will be reserved for pre-test and post-test, but all other pairings will occur in the test phase, and one of them will be featured in the habituation phase.

LINKED prepost = {mip, round}
LINKED deeb_blue = {deeb, blue}
LINKED deeb_green = {deeb, green}
LINKED geff_blue = {geff, blue}
LINKED geff_green = {geff, green}

Groups

We'll define two groups consisting of our LINKED tags. Both will contain all of the possible pairings of deeb, geff, blue, and green. At the start of each test session, we will randomly select one pairing from the first group for the infant to see during habituation. The test phase for all infants will consist of all four pairings, so our test_trials group will also contain all four.

LET habit_pairs = {deeb_blue, deeb_green, geff_blue, geff_green}
LET test_trials = {deeb_blue, deeb_green, geff_blue, geff_green}

Experiment settings

Now we define our experiment settings. Because this protocol has a habituation phase, we must define all of our habituation criteria here.

DEFINE WINDOWSIZE 3
DEFINE WINDOWOVERLAP NO
DEFINE CRITERIONREDUCTION 0.65
DEFINE BASISCHOSEN FIRST
DEFINE WINDOWTYPE FIXED

We could also define key assignments for live-coding - without them, experimenters will use C for looks CENTER to the light/screen, and W for AWAY.

STEPS for execution

Pre-test

Now for the STEPs that will start once we run the protocol. First, we'll define our pre-trial phase. Before each trial, we'll have a center light flash until the infant is paying attention. We'll have the experimenter press C to begin a CENTER look.

STEP 1
Phase Pretrial Start

STEP 2
LIGHT CENTER BLINK 250
UNTIL KEY C

Once the infant is looking, we can start a trial. We'll turn off the light and display the pre-test stimuli. Note that because we defined the LINKED tag prepost with both an audio tag component and a video tag component, we can reference the LINKED tag in the action statements for both AUDIO and VIDEO.

STEP 3
LIGHT CENTER OFF
Trial Start

STEP 4
VIDEO CENTER prepost LOOP
AUDIO CENTER prepost LOOP
UNTIL SINGLELOOKAWAY prepost GREATERTHAN 1000
UNTIL TIME 14000

STEP 5
Trial End
VIDEO CENTER OFF
AUDIO CENTER OFF

STEP 6
Phase End

Our trials throughout the experiment will last a maximum of 14 seconds. Trials will end when we reach this limit, or when the infant is recorded as looking away for at least 1 second. There is only one pre-test trial, so once it is over, we end the phase and move on to habituation.

Habituation

As we start the habituation phase, the first thing we need to do is assign the participant randomly to a word-object pair that they will see during habituation. There were four possibilities in the habit_pairs group.

STEP 7
Phase Habituation Start
LET pair = (FROM habit_pairs RANDOM)

Having selected in advance which word-object pair the participant will see, we can define the inter-trial period (with the blinking light) and a habituation trial. Note that the pair tag we selected from habit_pairs is again a LINKED tag that can be referenced in both of the action statements to play the audio and video.

STEP 8
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 9
LIGHT CENTER OFF
Trial Start

STEP 10
VIDEO CENTER pair LOOP
AUDIO CENTER pair LOOP
UNTIL SINGLELOOKAWAY pair GREATERTHAN 1000
UNTIL TIME 20000

STEP 11
Trial End
VIDEO CENTER OFF
AUDIO CENTER OFF

We'll play the exact same stimuli for the rest of our habituation trials, so now we'll define a loop. We want to either keep playing trials until the infant meets our habituation criteria or reaches the maximum of 20 habituation trials (19 of them via the loop).

STEP 12
LOOP STEP 8
UNTIL 19 TIMES
UNTIL CRITERIONMET

STEP 13
Phase End

Note that our loop goes back to STEP 8, where we started the light blinking for the inter-trial period, but excludes the assignment of the dynamic tag pair back in STEP 7. This is why we chose which word-object pair would be presented before we needed to use it to display trial stimuli in STEP 10: we didn't want this LET statement to be included in the loop. We want this dynamic tag to be assigned as one pair and stay that way so that we are repeatedly presenting the same word-object pair. If the LET statement were inside the loop steps, we would repeat the choose statement on every loop iteration, and we would show different word-object pairings on different trials. In general, when you want to select from a group and be able to refer to the result of that selection throughout a phase, it's a good practice to make that selection in the same STEP where you define your phase's start. "Getting it out of the way" like this makes it easier to not accidentally loop over and reassign a dynamic tag that you would prefer to stay static.

Test phase

Once the infant has habituated or met the maximum number of trials, we move on to the test phase. We'll begin again with the inter-trial light flashing before beginning a trial.

STEP 14
Phase Test Start

STEP 15
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 16
LIGHT CENTER OFF
Trial Start

Recall that our four test items are all in the test_trials group, and are LINKED tags with all the possible pairings of the audio deeband geff, and the videos of the objects blue and green. We want to display these four word-object pairs in a random order, without replacement. We'll define one trial, then use a loop to run the remaining trials.

STEP 17
LET test_item = (TAKE test_trials RANDOM)
VIDEO CENTER test_item LOOP
AUDIO CENTER test_item LOOP
UNTIL TIME 14000
UNTIL SINGLELOOKAWAY test_item GREATERTHAN 1000

STEP 18
Trial End
VIDEO CENTER OFF
AUDIO CENTER OFF

The test phase is where we see the advantage of defining our pairs of tags via LINKED tags rather than selecting video and audio tags separately. If we had defined a test audio group and test video group, they would look like this:

LET test_audio = {deeb, deeb, geff, geff} LET test_video = {blue, green, blue, green}

With random selection from each in turn across trials, there would be nothing to stop us from repeating a pairing, and thus failing to show all the combinations of words and objects. For example, on our first test trial we could randomly select deeb and blue - but there is no way to specify that if we choose deeb again from the audio group, green must be selected rather than blue from the video group. We could define groups that would be chosen from in a fixed order, arranging each of the audio and video tags so that all the pairings are present when they are selected using FIRST (and creating multiple copies of this protocol to counterbalance test trial order.) But without LINKED tags, we could not use RANDOM selection in this protocol.

We'll use another loop to play the remaining three test trials, after our first one is done, and this concludes our test phase.

STEP 19
LOOP STEP 15
UNTIL 3 TIMES

STEP 20
Phase End

Post-test

Lastly, we have a post-test trial, which is identical to our pre-test phase.

STEP 21
Phase Posttest Start

STEP 22
LIGHT CENTER BLINK 250
UNTIL KEY C

STEP 23
LIGHT CENTER OFF
LET prepost2 = (TAKE prepost RANDOM)
Trial Start

STEP 24
VIDEO CENTER prepost LOOP
AUDIO CENTER prepost LOOP
UNTIL SINGLELOOKAWAY prepost GREATERTHAN 1000
UNTIL TIME 14000

STEP 11
Trial End
VIDEO CENTER OFF
AUDIO CENTER OFF

STEP 26
Phase End

Now our experiment is done!

See the resources page for a copy of this protocol.

About this protocol

This protocol demonstrates a common application of a conditioned headturn procedure: signal detection. It isn't strictly based on any particular study, although it is similar conceptually to many in the realm of infant signal detection in noise, e.g. Trehub, Bull, & Schneider 1981; Werner & Bargones 1991.

In this example study, multi-talker background noise plays continuously throughout. During some trials, an additional voice that repeatedly calls the participant's name begins playing too. When the name is being called and the participant turns toward the source of the voice (a "hit"), they are rewarded with a desirable stimulus (e.g. a toy being lit up or beginning to move). When the name is being called but their behavior does not indicate that they detected it (i.e. they don't turn toward it - a "miss"), the reward stimulus is not presented, nor is it presented when the name is not being played, whether they turn (a "false alarm") or not (a "correct rejection").

This is a simple example of a signal detection task because during the test phase, it does not adjust the intensity of the signal (voice calling the name) relative to the noise, as you would when attempting to establish a detection threshold.

Starting the protocol

Starting definitions

This protocol will use two separate channels on a DMX dimmer pack. In the protocol we'll refer to these as LIGHT LEFT and LIGHT RIGHT, but crucially, these won't both correspond to lights.

The LEFT light will be our reward stimulus. Depending on the implementation of conditioned headturn, it might be an actual, simple light that illuminates an otherwise invisible toy. Or the "light" might be a plugged-in device or electronic toy that will begin to move when receiving power - BITTSy doesn't know the difference!

The RIGHT light will refer to an empty channel on the dimmer pack, with either nothing plugged in or something plugged in that will remain powered off regardless of the dimmer pack command (i.e. by having the power switch on the device be in the off position). We need this empty channel so that trials can always be structured the same way, whether they are trials with a potential to show the reward or not.

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

The above are our starting definitions. However, if you have more lights connected in your system (e.g. for headturn preference procedure) and will be leaving them all connected during testing, you may need to define more lights so that you can identify which channel has the reward stimulus and which is empty.

Tags

Now we'll define our tags that reference files. We have only audio files for this type of study. One is the background noise that will play continuously throughout. Then we have our signal of interest - the file that contains the voice calling the participant's name. We'll call this audio file changestim. We'll need another to be the controlstim so that regardless of the trial type, we've got a command to play an audio file. But in this case, the control stimulus is actually a completely silent file, since we're interested in comparing the presentation of the name to a case where the background noise simply continues with nothing else added.

LET noise = "C:\Users\ldev\Desktop\BITTSy\ConditionedHeadturn_signaldetection\9-voices.wav"
LET changestim = "C:\Users\ldev\Desktop\BITTSy\ConditionedHeadturn_signaldetection\Alexis.wav"
LET controlstim = "C:\Users\ldev\Desktop\BITTSy\ConditionedHeadturn_signaldetection\silence.wav"

Groups

We'll use groups to set up a key aspect of this paradigm: the "change stimulus" or signal of interest (the voice calling the participant's name) gets paired with the reward stimulus (plugged into the LEFT light channel) and the "control stimulus" (the absence of the voice - a silent audio file) does not.

A "change trial" will use both the "change" stimulus and the LEFT light. So we'll define a group that pairs them, called changetrial.

LET changetrialstim = {changestim}
LET changetrialside = {LEFT}
LET changetrial = {changetrialstim, changetrialside}

Similarly, we'll make a controltrial group that pairs the "control" stimulus (silence) with the empty RIGHT channel, so that this trial type can have the same structure within the protocol, but not actually turn on a device.

LET controltrialstim = {controlstim}
LET controltrialside = {RIGHT}
LET controltrial = {controltrialstim, controltrialside}

Now that we have structures representing change and control trials, we can define the groups that we'll use to present these trial types within phases - training phase, conditioning phase, and test phase.

LET training = {changetrial}
LET conditioning = {changetrial}
LET test = {changetrial, controltrial}

In this study, we can choose to not include control trials in the training phase - since the control trials are the absence of the voice and absence of the reward stimulus, the gaps between change trials essentially function as reinforcing that the reward does not occur until the change stimulus is present. A study focusing on discrimination between two signals, where one is rewarded and the other is not, would likely have control trials during training. But it is not necessary here, so the training group can contain only changetrial.

The conditioning phase will also only contain change trials - the goal of this phase, after the initial exposure to the paired signal and reward in the training phase, will be to ensure that the participant predicts the reward after hearing the stimulus, and makes an anticipatory turn toward the location of the reward.

The test phase will contain both change trials and control trials. Here, we'll have them occur with equal probability, but we could weight the relative probabilities by adding more change trials or more control trials to the test group.

Experiment settings

There are no special experiment settings required for this protocol. However, if we planned on using the reporting module to analyze participant logs, it is helpful to make sure that the key that is used to mark the participant turning toward the signal matches the key assigned to the LEFT side (where the signal will be presented). That way, the turn is logged as a look toward that stimulus rather than just a timestamped keypress, and we can easily summarize which trials had turns and the time it took before the participant turned via a standard report of looking time by trial. This protocol is configured to use L, the default key for LEFT, so it doesn't require a key assignment definition, but if you wished to use another key other than L, you could include one in this section.

STEPS for execution

Training

First in this study, we'll start playing the background noise file that will play on loop throughout the entire study. Then we'll want to wait until the experimenter judges that the infant is ready for a trial to start. (Typically in conditioned headturn studies, a second experimenter sits in front of the infant to engage their attention with some small toys, and the experimenter running the protocol would wait until the infant was attending to the toys, relaxed and unfussy.) We'll have the main experimenter press C when the infant is ready.

STEP 1
Phase Training Start
AUDIO CENTER noise LOOP

STEP 2
UNTIL KEY C