Timing Accuracy if Multiple Stimuli presented per block

Home Forums Support Timing Accuracy if Multiple Stimuli presented per block

  • This topic has 2 replies, 2 voices, and was last updated 9 years ago by Liz.
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #1802
    Liz
    Guest

    Hi there,

    This question pertains to the accuracy of timing information if I present multiple stimuli within the same loop and merge block. I was finding that the Intertrial Delay was too long (mostly due to the long InitPre duration). To overcome this problem, I’ve instead built my experiment with multiple Stimulus Items in the same block (each item is labeled uniquely and has the Javascript associated with a stimulus). The first item in the block is an Init item and the last item in the block is an Exit item. The stimulus being presented in Stimulus 1 is ${lm://Field/1}, in Stimulus 2 is ${lm://Field/2}; in Stimulus 3 is ${lm://Field/3}, and so on. I’m essentially using the loop and merge capabilities to randomize the order of my stimuli. That is, in Excel I have randomized the order of my stimuli multiple different times. Each column in the Loop and Merge feature is a stimulus, and each row is an ‘order’. I have it set to randomly sample 1 row of the Loop and Merge fields.

    My question is two-fold: 1) will the timing data be accurate if I present my stimuli this way, or is there something about the InitPre duration that ensures the timing accuracy? What I’m worried about is that the timing data for my first stimulus will be accurate, but that the timing for the say 20th stimulus will no longer be accurate. 2) Do you know of any way to format my embedded data or to modify the Parser so that I can use the Parser to obtain this information. I’m fine with the painstaking process of going into the csv that Qualtrics outputs and obtaining the RT values from the Exit_1_TEXT cell, but I’m wondering if you have any recommendations for how to segment this information properly. Maybe you have the raw javascript for the parser that you created that I could look at and try to adapt?

    Thank you so much in advance for your help on this issue.

    Best,

    Liz

    #1846
    Erwin Haasnoot
    Keymaster

    Hi Liz,

    Good question! We haven’t specifically stress-tested our Engine this way, ie, having 1000 stimuli in one trial. I can foresee several problems arising as the amount of stimuli grow. Specifically, the initialisation phase could start taking very long, and the memory requirements of running a task could be too much for a user’s computer. But this would maybe start happening at around 10,000 stimuli per trial. Even so, the within-trial timing would not be affected too much, as the algorithm being used only handles the stimuli as a queue, and then only the previous, the current and the next stimuli in the queue. This way, timing shouldn’t be affected by the amount of stimuli in a trial.

    As for the second part of your question.
    There is some flexibility present in the current parser, related to the way the JSON configuration file is set-up. This feature is barely used, even by me, so I’d need to look into that again to see what’s possible.
    Also, The source code of the parser is freely available here: https://github.com/ErwinHaasnoot/QRTEParser (the main file is here: https://github.com/ErwinHaasnoot/QRTEParser/blob/master/com.eclipsesource.json/src/com/qrtengine/parser/QRTEParserMain.java). It’s written in java, not javascript, and is not very well documented, but if this would help you fix your problem, please don’t hesitate to take a look at it!

    Best Regards,

    Erwin

    #1852
    Liz
    Guest

    Thanks so much Erwin!

Viewing 3 posts - 1 through 3 (of 3 total)
  • The forum ‘Support’ is closed to new topics and replies.