Millisecond Forums

Dear Millisecond team,

in our daily work with Inquisit we encountered a few cumbersome issues that probably could be assessed quite easily and would provide a much smoother operation. These are:

(1) Save name of exp file in output file. We often conduct experiments where subjects need to complete an experiment multiple times, with slightly modified and individual stimulus parameters/timings/instructions. We usually code these changes in the name of the exp-file to be able to quickly identify what has been altered for the said run. Unfortunately, Inquisit won't store the name of the exp file in the output file, which can become nasty if the connection between an output file and the generating exp file cannot be made upon data analysis (which may happen weeks after the experiment finished).

(2) New output file per run. We usually conduct data analysis on a per-subject basis before merging all data together. Since Inquisit will not allow single data files for each experimental run, data sets for individual subjects need to be extracted from the full file manually, which is error-prone and unnecessary. Although there is a workaround by connecting a local drive as a network share, it would be beneficial to have a simple boolean switch "individualfile" to be specified in the data element of the exp file.

(3) Warning/Save option if save path is unavailable. This is connected to the previous point. We always save on network shares to have individual output files per subject and experimental run. Unfortunately, network shares are not always reliable due to connection problems, timeouts or other unforseen forces. Inquisit will not issue an error if a network share is unavailable, worse still, even if the network share is unavailable at the beginning of an experimental run, Inquisit will happily excute the whole experiment, terminate correctly but just not save the data. This happened to us quite a few times, we lost hours of subject generated data only due to such incidents. It would be nice to have Inquisit at least issue a warning prior to the experiment or - even better - open a save dialog at the end of an experimental run in case the target output location is unavailable.

(4) Use ISIs instead of SOAs. We'd be very happy if you'd consider implementing an ISI based timing control scheme. Depending on SOAs means that you always need to change the complete series of timings in a trial, which can sensibly only be accomplished with the help of some spreadsheet program or self-written software. Using ISIs would make things much easier, since the dependency between the timings would allow for changing only selected timings and automatically adjusting all subsequent timings.

(5) Introduce user-defines. Typically, our experiments comprise numerous trials (accounting for presentation order, experimental condition, stimulus pairings, asf.), where settings need to be customized for each subject in order to match subject ability and difficulty level. Having many trials often compels us to change the same value over and over again, which is laborious and not especially fail-safe. Providing "defines" (like in C) or named constants, which require only a simple search-replace operation on the exp file prior to interpretation of the file, would significantly alleviate things.

We'd be very happy if you considered our suggestions valuable and compatible with the existing codebase of Inquisit.

Kind regards,
  Malte Persike