Shaun,
thanks for replying so fast. Agreeably, (4) has been stated somewhat nebulous, so I'll try to rephrase that.
Say, you'd want to have a trial set up like this
0 ms:blank - 40ms:firstpic -140ms:mask - 240ms:blank - 280ms:secondpic - 380ms:mask - 480ms:blank
Currently, one has to specify such a trial this way:
/ stimulustimes = [0=blank; 40=firstpic; 140=mask; 240=blank; 280=secondpic; 380=mask; 480=blank]
which is intuitively clear and a direct translation of the demanded trial course. However, suppose you want to measure psychometric functions dependent on time, meaning you'll need to adjust the timings individually for every subject. Changing, for example, the presentation time of "firstpic" and "secondpic" from 100ms to 150ms thus requires changing
all timings after firstpic, like this:
/ stimulustimes = [0=blank; 40=firstpic; 190=mask; 290=blank; 330=secondpic; 480=mask; 580=blank]
Plus, a quick inspection about correctness of the specified timings is not the most pleasent thing to do because you have to go through a lot of mental subtracting.
Instead, I propose the ability to specify ISIs (inter stimulus intervals), like so:
/ stimulustimes = [40*blank; 100*firstpic; 100*mask; 40*blank; 100*secondpic; 100*mask; 40*blank]
The two advantages here are apparent: a) modifications to the time course require only a change of the specific timing parameter in question, not of anything else, and b) even a short glimpse at the code readily informs you about how long firstpic and mask are presented. I'd in any case prefer such a timing definition scheme over the SOA logic implemented by Inquisit. But that may be only because I'm from the psychophysics department...
Best wishes,
Malte