Millisecond Forums

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