Sample per condition

Show each participant a fixed number of trials per difficulty level, drawn fresh from a larger pool every session.

When to use it

Use this when the stimulus pool is bigger than any one session should be, and you want conclusions about the conditions rather than the particular items. Hand-picking a fixed subset shows every participant the same items, so item quirks masquerade as condition effects; sampling without a per-condition constraint is little better, since an unlucky draw can leave the difficulty levels unbalanced. Drawing a fixed number per condition, fresh each session, spreads items across participants while keeping every session balanced. If each participant should see the whole pool, a plain shuffle is all you need.

Trial file

type	content	stimFormat	stim1	condition1	trialOrder	keyboard	key	button1
instructions	Press C for cat and D for dog.							NEXT
test		.png	cat_clear	easy	1: sample 2 condition1	c d	c
test		.png	dog_clear	easy	1	c d	d
test		.png	dog_park	easy	1	c d	d
test		.png	cat_faint	hard	1	c d	c
test		.png	dog_faint	hard	1	c d	d
test		.png	cat_blur	hard	1	c d	c

How it works

The pool holds more trials than any participant will see, with each row tagged by difficulty in condition1. The trialOrder column does the rest: every pool row carries the group tag 1, so they are handled as one group, and the first row’s cell adds a sampling spec, 1: sample 2 condition1, which both picks the trials and shuffles what it keeps. That spec keeps 2 randomly chosen trials per distinct condition1 value (2 easy plus 2 hard here) and drops the rest, so each session presents 4 trials in a fresh random order. Write the spec on the first row of the group only; every other row of the group takes the bare tag 1.

condition1 pulls double duty: it is the grouping column the sampler counts by, and it is echoed into every results row, so the analysis already knows which difficulty each kept trial had. The instructions row has an empty trialOrder cell, so it stays put as a fixed boundary in front of the shuffled pool.

key names the correct response key for each image, and keyboard restricts responses to those keys, so accuracy is scored per kept trial.

Variations

• Sample an overall total instead of per level: 1: sample 4 in trialOrder keeps 4 trials regardless of their condition1 value.
• Thin only one level: 1: sample 2 condition1 hard in trialOrder samples the hard trials down to 2 and keeps every easy trial.
• Keep whole levels rather than trials: 1: groupSample 1 condition1 in trialOrder keeps all trials of 1 randomly chosen difficulty and drops the other level entirely. The kept level plays in trial-file order, so write 1: groupSample 1 condition1; shuffle if those trials should be shuffled too.
• Add an ordering constraint on top by separating specs with ;, for example 1: sample 2 condition1; maxRun 2 condition1 in trialOrder.

A spelling slip inside the spec is not silent: any colon cell in trialOrder that fails spec parsing (say 1: sampel 2) is rejected when the trial file is saved, and a sampling error at runtime halts the session with an error page rather than running unsampled.