Multi-column list file

Give every generated trial its own settings, such as the correct key, from extra columns in the stimulus list CSV.

When to use it

List-driven trials normally inherit everything from the one row they expand from, which works until items need to differ in more than the stimulus: a cat photo and a dog photo cannot share one correct key. Rather than falling back to one hand-written row per item, add columns to the list CSV itself; each extra column is merged into the generated trial, so per-item scoring, condition tags or timing live next to the stimulus they belong to. If all items are treated identically, the plain single-column list (see the trials from a stimulus list recipe) is all you need.

Trial file

type	content	stimFormat	stim	listOptions	keyboard	key	condition1	button1
instructions	Press C when the photo shows a cat and D when it shows a dog.							NEXT
practice		list	animals	sample 2	c d
instructions	End of practice. The scored block starts now.							NEXT
test		list	animals	random	c d

How it works

The list is uploaded to the Files tab as animals.csv. Its first column, stim, holds the items (extensions included); every further column is a per-item value:

stim	key	condition1
cat1.jpg	c	cat
cat2.jpg	c	cat
dog1.jpg	d	dog
dog2.jpg	d	dog

stimFormat: list plus stim: animals expands each list row into a generated trial, exactly as in the single-column case, with the type derived from the first picked item’s .jpg extension. The extra columns are then merged into each generated trial, and the merge rule is blunt: a value from the CSV overwrites whatever the trial-file row has in that column, so even a filled base cell would lose to the list. The column headers must exactly match the column names used in the trial file, which is why the trial file carries key and condition1 columns even though their cells on the list rows stay empty.

The division of labour follows from that rule. Anything constant across items stays on the base row: keyboard restricts responses to C and D for every generated trial, and listOptions picks 2 random practice items then shuffles the full set for the test block. Anything per-item lives in the CSV: key names each item’s correct response, scored into the correct results column (correctPractice on the practice rows), and condition1 tags each trial with its category, echoed into every results row so the analysis can split by condition without parsing filenames.

Write the CSV’s key values in lowercase. Scoring is case-sensitive with a twist: a response matching the key only after ignoring case is recorded as unscored (blank correct) rather than incorrect, which quietly thins your accuracy data.

Since both rows draw from the same list, the two practice items also reappear in the test block; split the pool into two list files if practice stimuli must stay out of the scored data.

Variations

• Per-item timing: add a presTime column to the CSV; its values override any base-row presTime, so fast and slow items can coexist in one block.
• Two stimuli per generated trial: add a stim2 column to the CSV, and the pairing travels with the item.
• Per-item feedback: a feedback column in the CSV shows a different message after each item.
• Fixed session length: replace random with sample 10 in listOptions to draw 10 items per session from a larger CSV pool.