[solved] importing modules slows trials down?

Comments

• sebastiaan

  May 2012 edited May 2012

  Hi Markku,

  The import statements shouldn't slow things down in any noticeable way, except the first time. I suspect that the trial_sequence contains some things that need to be prepared, such as sketchpads, synthesizers, etc. The way it works is that these items are prepared before the execution of every sequence, to minimize timing glitches during the sequence, at the expense of some unpredictable variation between sequences.

  What I usually do is insert a blank display (or fixation dot) at the end of the sequence. That way the participants don't feel as though the experiment is 'sluggish'.

  Does that answer your question?

  Cheers,
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• mkilpela

  May 2012 edited 1:13AM

  Thanks,

  Ok, a blank screen with a fixation mark could suffice. What would be even better is displaying the (variable) preparation screen of the next trial. Is there any way to get a block variable value of the next trial. I suppose I need to see if there I can streamline my stimulus code a bit as well:)

  Markku
• sebastiaan

  May 2012 edited 1:13AM

  Well, what you could do is insert an inline_script at the start of the trial sequence to show a display already in the prepare phase (inline_scripts have different tabs for both phases). This is unconventional, because the prepare phase is usually the place where you would engage in invisible preparatory stuff. But nothing stops you from breaking convention.

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• ezerkar

  May 2012 edited 1:13AM

  FYI, if you are using the legacy back-end, cancelling the double buffering and the hardware surface realy speeds things up (at least for me it did, I'm using an eight yearold computer though). I guess it has it's disadvantages but for me it prevented 0.5 sec trials to become 1.5 secs, which would of made my experiment pretty tiresome.

  Ezer