Millisecond Forums

ok... thanks for your help!

Offhand, no I don't think there is an obvious way to get rid of the lag under Windows -- there are different underlying platform APIs under Windows and Mac, and in this case the OSX media APIs handle the situation more efficiently than the Windows APIs are able to.

Hi again, 
We've tried a few other things and here's what we get: 

On Mac : 3x3 with only 30 trials works fine (on multiple machines with different processing and graphics power). 
On Windows (both computer are OK... not super powerful but not too old - probably your average Windows's user computer). 
- 3x3 with only 30 trials is very slow - each stimuli takes "time" to load - i.e. they lag quite a bit. 
- we're tried using .wmv files on Windows (although larger then the mp4 files - 400kb vs. 80kb) they also lag/are slow. 
- we're tried a 2x2 matrix - and the still lag with mp4 files.  

At this point - we got it to work reliably on Mac - but we have yet to make it work the same on Windows. Are we still stuck with a script/hardware limitations - or is there anything we can do to make the Windows script not lag?
?

Having taken a look at the scripts as they are deployed online, I do _not_ think that the "unnecessarily" downloaded videos (i.e. those of the condition _not_ administered to the given participant) should have a detrimental effect on the scripts' runtime performance. However, if you _do_ wish to avoid even downloading any unnecessary videos, you can achieve that by using conditional <include> elements instead of using the <variables> element to assign item elements as distractors and targets. So instead of

<variables>
/ group = (1 of 2) (distractoritems=distractoritems_experimental, targetitems=targetitems_experimental)
/ group = (2 of 2) (distractoritems=distractoritems_control, targetitems=targetitems_control)
/ groupassignment = groupnumber
</variables>

you would use <include> elements like so

//1st condition: experimental
<include>
/ precondition = [mod(script.groupid,2) == 1]
/ file="experimental.iqx"
</include>

//2nd condition: control
<include>
/ precondition = [mod(script.groupid,2) == 0]
/ file="control.iqx"
</include>

where "experimental.iqx" contains

*** Target items ***
*** Experimental condition ***
<item targetitems>
/ 1 = "s1.mp4"
/ 2 = "s2.mp4"
/ 3 = "s3.mp4"
/ 4 = "s4.mp4"
/ 5 = "s5.mp4"
/ 6 = "s6.mp4"
/ 7 = "s7.mp4"
/ 8 = "s8.mp4"
/ 9 = "s9.mp4"
/ 10 = "s10.mp4"
/ 11 = "s11.mp4"
/ 12 = "s12.mp4"
/ 13 = "s13.mp4"
/ 14 = "s14.mp4"
/ 15 = "s15.mp4"
/ 16 = "s16.mp4"
</item>

*** Distractor items ***
*** Experimental condition ***
<item distractoritems>
/ 1 = "r1.mp4"
/ 2 = "r2.mp4"
/ 3 = "r3.mp4"
/ 4 = "r4.mp4"
/ 5 = "r5.mp4"
/ 6 = "r6.mp4"
/ 7 = "r7.mp4"
/ 8 = "r8.mp4"
/ 9 = "r9.mp4"
/ 10 = "r10.mp4"
/ 11 = "r11.mp4"
/ 12 = "r12.mp4"
/ 13 = "r13.mp4"
/ 14 = "r14.mp4"
/ 15 = "r15.mp4"
/ 16 = "r16.mp4"
</item>


and "control.iqx" contains

*** Target items ***
*** Control condition ***
<item targetitems>
/ 1 = "fl1.mp4"
/ 2 = "fl2.mp4"
/ 3 = "fl3.mp4"
/ 4 = "fl4.mp4"
/ 5 = "fl5.mp4"
/ 6 = "fl6.mp4"
/ 7 = "fl7.mp4"
/ 8 = "fl8.mp4"
/ 9 = "fl9.mp4"
/ 10 = "fl10.mp4"
/ 11 = "fl11.mp4"
/ 12 = "fl12.mp4"
/ 13 = "fl13.mp4"
/ 14 = "fl14.mp4"
/ 15 = "fl15.mp4"
/ 16 = "fl16.mp4"
</item>

*** Distractor items ***
*** Control condition ***
<item distractoritems>
/ 1 = "fl17.mp4"
/ 2 = "fl18.mp4"
/ 3 = "fl19.mp4"
/ 4 = "fl20.mp4"
/ 5 = "fl21.mp4"
/ 6 = "fl22.mp4"
/ 7 = "fl23.mp4"
/ 8 = "fl24.mp4"
/ 9 = "fl25.mp4"
/ 10 = "fl26.mp4"
/ 11 = "fl27.mp4"
/ 12 = "fl28.mp4"
/ 13 = "fl29.mp4"
/ 14 = "fl30.mp4"
/ 15 = "fl31.mp4"
/ 16 = "fl32.mp4"
</item>

Dear Dave... I'd like your input on the following issue regarding the video overload. 

At this point we've split the task into 3 scripts - and we have participants/scripts redirect to one another. It seems to "work" OK, but we're always looking for ways of making it more efficient. MY QUESTION - as it stands, each scripts has both experimental (faces) and control (flowers) embedded, and "group" number assigns participants to condition - this also means that the scripts loads ALL stimuli - do you think it would run faster or be less likely to be overloaded with videos if I separated the scripts - i.e. one script for only Faces and a second one only Flowers? In other words, is the script has fewer videos embedded in it - do you think this would lessen the "overloading" or is more an issue of actually showing stimuli and graphic memory capacity?

Thanks in advance, 
Stéphane

Got it. Thanks for the help. I'll try the script you suggest and also setting up 3/4 separate scripts that link to one another (with different url's that is).
 

You could -- maybe -- set up your <batch> script like so:

//part 1
<batch>
/ subjects = (1 of 3)
/ groupassignment = groupnumber
/ file = "part_01.iqx"
</batch>

//part 2
<batch>
/ subjects = (2 of 3)
/ groupassignment = groupnumber
/ file = "part_02.iqx"
</batch>

//part 3
<batch>
/ subjects = (3 of 3)
/ groupassignment = groupnumber
/ file = "part_03.iqx"
</batch>

Now, if you provide 1 as the groupnumber (by entering it in Inquisit Lab, or by supplying it via a query parameter in Inquisit Web), the batch will run "part 1". Then the app will shut down. You can then continue with "part 02" by restarting things, but provide 2 as the groupnumber. Part 02 will be run, and then the app will shut down. You can then initiate part 03 by supplying 3 as the groupnumber. Or you could repeat any of the parts in case of a crash or substantial lagging midway through by restarting things with the respective groupnumber specified (e.g. provide 2 if you want to run part 02 again).

I do not, however, see any way to have a script "continue where it left off" in case lagging or a crash occurs midway through.

Does that make sense?

OK got it. I've tried putting 3 scripts in a batch (each have 25 trials)... and the task starts bugging after the seconds script. So... to "reboot", I have to exit/close the plugin then start again.. is that correct? In other words, I'm thinking of decreasing the number of videos per screen.. but also need to keep the number of trials relatively high, therefore I'm also looking for option to "replay" or "continue" with the same script. 

> It looks like the task gets overloaded by the video stimuli.

This is likely exactly what happens -- displaying between 9 to 16 videos _simultaneously_ in every trial puts significant load on the system as a whole, and frankly neither Inquisit nor the operating frameworks were built to handle such a scenario well. At some point, the system is likely to run out of available main and/or graphics memory, potentially leading to an application crash. While -- ideally -- Inquisit should not crash, we would not make any timing guarantees under the given scenario. So, I honestly don't think there is a way to really "fix" this short of significantly reducing the amount of simultaneously displayed videos. As for the crashing itself, the next release of Inquisit 5 should handle that better, but the general problem -- the script becoming laggy as the number of presentations increases and associated timing issues -- will remain.