I just realized that the wishlist I once compiled for Inquisit 2 (http://www.millisecond.com/forums/Topic1118.aspx) has been covered nearly in its entirety by the new features Sean Draine and his team weaved into Inquisit 3 since then. That's why, at first, I wish to say many, many thanks from a grateful user! This is truly great customer support from a truly great team.

But as software can never satisfy men, I felt now would be a good time to put up a new wishlist from observations I made and issues I stumbled upon while working with Inquisit. I tried to incorporate mostly those nitpicks that at least one other user brought up in the discussions on this forum. So here we go.

(1) Allow <values> as trial timings: The timing/frame specification is one of the roughest edges about Inquisit I am aware of. Variable or adaptive presentation times are impossible to implement with the current logic and above all, changes to the timing of a certain stimulus within a trial event train require to change all subsequent timings accordingly.

(2) Evaluate a <picture> element every time it is used: Many research paradigms involve presenting some target stimulus among a number of distractor elements. These distractor elements are often visually different (e.g., letters in different orientations) but belong to the same conceptual class and thus lend themselves to be defined within the same <item>. It would be intuitive to only declare a single stimulus element for such an item and reuse that multiple times within the same trial. Inquisit precludes such efficient coding since it will evaluate the same stimulus only once at the beginning of a trial and then show exactly this instance on every occasion it is used within that trial.

(3) *SOLVED (http://www.millisecond.com/community/forums/t/1292.aspx)* Make <picture> elements objects that can be passed around: This is a minor one, agreed, but most probably something you will bump into when exploiting the more sophisticated aspects of expression based programming in Inquisit. Many of Dave's examples for efficient coding involve the use of <text> stimuli and the ability to assign a string to the item property of a text stimulus during runtime. This allows for something like

  <text illshowanything>
  /item = ("<%values.sometext%>")
  </text>

where you'll only need a few text items in your whole script to display even large numbers of different text stimuli. A similar thing cannot be done for pictures due to the preloading of the associated files. It would nonetheless be a most convenient feature if Inquisit made something like this possible:

  <picture illshowanything>

  /item = ("<%values.somepic%>")

  </picture>

(4) Preserve transparency given in picture files: I never understood why Inquisit, despite its DirectX roots, even ignores the transparency setting of GIF files and instead only provides the ability to set one fixed color transparent manually. Full alpha channel transparency would open Inquisit to a whole new universe of experiments particularly in the vision sciences. Keep in mind, however, that enabling alpha channel transparency would inevitably create the need for PNG support.

(5) Include subject id in data file name: This is self-explanatory. Putting the subject number/id into the data file name when separatefiles=true enables quick selection of files belonging to one subject.

(6) Enhance editor: How about code-folding, syntax highlighting, delimiter matching, an improved search-and-replace dialog with RegEx capabilities, selection search and proper notification about replacement results? There are highly sophisticated free editors on the market which can do all this and much more, why not enable their integration with the Inquisit IDE?

(7) Have a none-visual monkey that executes an experiment as fast as possible (ignoring the trial timings): And at best one who writes out data even after the trial period has expired. I explained that in more detail here, but to put it short, such a monkey would be a blessing to those of us who cannot afford Inquisit licenses for every notebook which scripts are developed on. My ususal routine when compiling a new experiment is to first code the script to the best of my abilities, then let the monkey do a test run, set up analysis and testing routines for the written data, and finally conduct the experiment myself to get a feeling for the possible caveats plus having some real-life data upon which timings can be evaluated. The monkey part is essential since it will reveal any programming flaws, faulty stimulus assignments, improper condition balancing and so forth. Unfortunately, our lab is pretty busy most of the day so computer time is a valued resource. A none-visual monkey that executes the experiment in silence as fast as possible and keeps writing out data would shorten the development process significantly.
I can see that Sean rather have me buy a license for my development notebook but why not offer something like a 20$ development license that writes out data only when in monkey mode. I'd buy one.

(8) Setting mouse cursor coordinates: In many paradigms,
particularly when eyetracking is involved, it is of high importance
where a subject fixates when a stimulus is presented. Not being able to
control where the mouse cursor is positioned if the task involves mouse
movements poses a significant problem.

(9) Expressions in <%...%> context: It would be great if
you could write, for example:

  / items = ("<%concat(capitalize(values.sometext),values.someothertext)%>"

(10) Multiple <values> objects: Why not make <values>
into named objects so that you can have multiple value groups in a
script. Would allow for cleaner, more structured code.

The list will be updated with suggestions appearing in later posts.

Kind regards, Malte

p.s.: Ah, and please fix the editor before launching 3.0.5.0. Its disregard for line endings when copy-pasting drives me nuts.

First, I'd like to second all of Malte's well thought out suggestions -- many of these are also on my list (I really have one) plus a lot more.

However, this should already be possible. Indeed (as you noted), to get this to work you have to make sure that the picture files get preloaded (or parsed) at the very beginning of the experiment. To that end, I usually stuff all these pictures into an <item> element:

<item picstopassaround>
/ 1 = "apicture.jpg"
/ 2 = "anotherpicture.jpg"
/ 3 = "yetanotherpicture.jpg"
[...]
</item>

Note that you do *not* need an actual <picture> element that would reference the above <item> element (via '/ items = picstopassaround'). The picture files contained in the item element will be parsed and thus will be adressable by their names (e.g. "apicture.jpg") and can be handled just like text strings via

<picture illshowanything>
/ items = ("<%values.somepic%>")
[...]
</picture>

or similar techniques.

~Dave

I created a new thread for this. See here: http://www.millisecond.com/forums/Topic3960.aspx

(8) Setting mouse cursor coordinates: In many paradigms, particularly when eyetracking is involved, it is of high importance where a subject fixates when a stimulus is presented. Not being able to control where the mouse cursor is positioned if the task involves mouse movements poses a significant problem.

Malte.

Hi Malte,

Thanks much for the feature suggestions. Here are some comments:

1) Without doubt, this feature would simplify programming for a lot of Inquisit scripts, and I've gotten a lot of requests for this (including a coupe from Dave, as I recall). It's on top of the list for Inquisit 4. At a minimum, this will be supported via expressions (e.g., trial.example.stimulusframes.3 = picture.mask;). Possibly this could be added to the the /stimulusframes command itself, although that might make the syntax of that command too complicated or lead to some ambiguities.

2) I agree, also a good feature to have, and also on the list.

3) As Dave pointed out, the only trick is to make sure you have an <item> set defined for all of the pictures so that Inquisit preloads them. Having done that, you can assign the items to any given <picture> element. I've thought about adding the ability to load picture files on demand, but that could introduce timing delays into an experiment, and cause situations where the experiment fails at run time (as opposed to compile time) because it can't find a picture file.

4) The only reason this hasn't been done is that Inquisit uses DirectDraw, the 2D graphics API, which does not have support for alpha-blending. Moving to Direct3D is a possibility, but unfortunately, Direct3D doesn't play well with the standard Windows APIs for presenting text, video, buttons, textboxes, etc. In any case, I agree this would be a good thing, and it's on the list.

5) Yes, this makes perfect sense.

6) Great suggestion, and you are probably right about being able to purchase such an editor.

7) Great idea, I've often wished I had a "fast" monkey. I will also consider enabling saving monkey data (both fast and slow) in evaluation mode. This definitely seems reasonable. I have a number of other ideas for making the monkey smarter as well.

8) Shouldn't be hard to add. Of course, this is going to "recalibrate" the relationship between the mouse on the pad and the cursor on the screen, but I'll assume that's acceptable.

BTW - while we're on the subject, here are a few other expression enhancements I'm planning to add:

1) Increment operators (e.g., values.duration += 200; values.trialcount++; values.remainingtrials--; values.score *= 10)

2) Methods on objects (e.g., counter.targets.additem("foo"); )

3) Expressions in list attributes (e.g., /trials = [1-10 = noreplace(counter.group1picker, counter.group2picker, values.distractortrial)] ). This allows higher order randomization, such as randomly selecting from sets that randomly select trials, stimuli, or blocks.

4) if->else if->else if->else if->else

5) More events where logic can be inserted (e.g., element.onload , stimulus.onprepare, stimulus.onselect, counter.onselect)

6) possibly some simple loops, such as while (true) { } and do{} while(true), although not sure about this one yet

Anything else you'd like to see?

-Sean

About the editor issue: I didn't mean to purchase such an editor (either by Millisecond or the user) but resort to the free alternatives out there. For example, Scintilla (http://www.scintilla.org/) is a free editor component, the license of which permits to even use it in commercial projects. My idea would be to provide the option of integrating certain editors into Inquisit and use them as an alternative to the built-in component.

My opinion about the expression enhancements:

1) Increment operators (e.g., values.duration += 200; values.trialcount++; values.remainingtrials--; values.score *= 10)

Very nice to have but not a must.

2) Methods on objects (e.g., counter.targets.additem("foo"); )

From a programmer's perspective: YES. From a user's perspective: You can do this already with getitem/insert/setitem. I would either opt to make everything strictly object oriented or leave things as they are.

3) Expressions in list attributes (e.g., /trials = [1-10 =
noreplace(counter.group1picker, counter.group2picker,
values.distractortrial)] ).

This is probably my number one if you would also consider to allow "/ items = someitem" in a counter. It would provide extreme flexibility when writing code. Make everything an object that can be passed around, so that texts, pictures, trials, blocks can all be loaded into counters. Of course, this would lead to a plethora of possible run-time errors.

4) if->else if->else if->else if->else

Nice to have, yet achievable by the current logic, although tedious.

5) More events where logic can be inserted (e.g., element.onload , stimulus.onprepare, stimulus.onselect, counter.onselect)

My number two on your list.

6) possibly some simple loops, such as while (true) { } and do{} while(true), although not sure about this one yet

I imagine a lot of tasks where loops as control structures would come in handy but all in all, to me the least important addition together with object methods, particularly with respect to the effort that would presumably go into this.

Thanks very much for replying,
Malte

Two more wishes.

(9) Expressions in <%...%> context: Maybe this works already and only I did not get it right so far. It would be great if you could write, for example "/ items = ("<%concat(capitalize(values.sometext),values.someothertext)%>".

(10) Multiple <values> objects: Why not make values objects named so that you can have multiple <values> groups in a script. Would allow for cleaner, more structured code.

Oh, if I may say the following, despite it being contrary to my own set of desiderata. I am profoundly unsure how many Inquisit customers really take advantage of the expression syntax. There is a huge difference between "normal" script writing and expression based coding which can be summarized in a simple antithesis: "users vs. programmers". The vast majority of Inquisit users I met had never written a single line of source code in their entire lifes and probably never will. They are not familiar with concepts like variables, functions, events, control structures and so forth. Handing some of Dave's wonderfully crafted scripting examples to any of my fellow lab members and ask them to a) understand and b) modify them would yield a river of tears - and resignations. Hence, although I should like to see Inquisit become more of a full blown programming environment, I strongly doubt that this is what most users require.

Inquisit's pivotal feature is that setting up functional scripts can be learnt within a matter of hours. Before adding features in the expression department, I'd always ask myself whether a similar thing could be achieved within the conventional Inquisit framework of elements, properties and dependencies. It's not helpful to include more and more functionality for less and less people until you reach the point where the latter might wonder why not use Matlab instead.

And now, nerd mode on again: yes, I love those expressions and what you can accomplish with them!

Malte.

Thanks for the pointer to scintilla. I will take a look, although I'm hoping to find one that has a Mac version as well. And free is great, but I haven't ruled out paying for a license if the quality is there. And, yes, this would replace the current editor component used by Inquisit. 

-Sean

Scintilla or at least parts of it are included in the wxWidgets library, so even without resting on GTK+, there is Mac compatibility. I may quote the Scintilla homepage: "The wxStyledTextCtrl editor component in the
wxWidgets cross platform toolkit is based on Scintilla."

And if you think about a licensing agreement with somebody, I'd vouch for UltraEdit. I love this editor and they are about to release a Mac version in the very near future.

Bye, Malte

Excellent! Thanks for the pointer. And like what I've seen of wxWidgets as well.

-Sean

Dear Sean,

I gave some thought to the enhancement of stimulusframes/stimulustimes while keeping in mind my above remark about not making things too complicated for the average user. Here's what I'd probably do: allow counters as timing specifiers. Just counters, nothing more. Dynamic timings could then be achieved without any need for expressions, as well as things like a timing "repository" where timings would be specified once within a script (i.e., in a counter) and then distributed across all trials.

Programmers should be even more satisfied if you additionally allowed expressions as elements in counters. If memory does not fail me, expressions can be embedded in counters but they only become evaluated once at the beginning of an experiment which does not suffice.


Enabling dynamic timing definitions by whatever means may bring a feature suggestion back to the table that I voiced a while ago: ISIs as an alternative to SOAs in a trial. My syntax would read

(1) The Inquisit SOA variant
/ stimulusframes = (1=pic1; 100=pic2; 500=pic3; 750=pic4; 900=blank)

(2) The ISI variant
/ stimulusframes = (99:pic1; 400:pic2; 250:pic3; 150:pic4; 1:blank)

The time course is identical in both variants (pic1 for 99ms, pic2 for 400ms, pic3 for 250ms, pic4 for 150 ms), only the definition is different. Following a cumulative timing scheme as granted by ISIs, counters could be employed with maximum flexibility for timing specifications.


To summarize:
(1) Allow counters as timing/frame specifiers in a trial
(2) Allow expressions in counters and have them evaluated every time the respective item is accessed
(3) ISIs as an alternative to SOAs for timing specification.


With that, I see no need for expressions in timing definitions, plus, most Inquisit users will already be familiar with all concepts required to set up dynamic timings.

Malte.

Not quite the same thing, but the following should work:

<values>
/ sometext = "a"
/ someothertext = "bracadabra"
</values>

<expressions>
/ myexpression = concat(capitalize(values.sometext),values.someothertext)
</expressions>

<text mytext>
/ items = ("<%expressions.myexpression%>")
</text>

~Dave

Hi Dave,

ever since some remote entity named D. pointed me to expressions I strive to have the number of trials in my scripts not exceed one. This requires to store the code of the current experimental condition into the trialcode at runtime. I'm using a lot of format() statements there and came up with the same solution as suggested by you. I find it funny, however, that expressions work and functions do not.

Bye, Malte.

How dare he do that to you?! Tell me where that guy lives and I'll go by his place and beat him up!

~Dave

Another feature request:

/ writetodatafile = true|false

as a <trial> attribute.

This way you could exclude none-essential trials (e.g., those which do not produce subject generated data) from being stored in the data file, thus making the data file more immediately analysis friendly.

Bye, Malte

The <trial> element already features the '/ recorddata' attribute which will do just that.

~Dave

Well, SOLVED, I guess...  *flushing*