[solved] problem with sound sampler

mariosav

Guys,
I've been banging my head for the last hour trying to solve a problem I have with an experiment. It's not urgent and I actually found a workaround already (...so no need to waste your Saturday night too on this!). But for the sake of my mental health, I need to understand what was causing the problem!

Basically, my trials are like this. First, a fixation is presented for 2s, then a blank screen (duration: 0) followed by a sampler item that plays a sound (duration: sound). Then I have an inline script that displays on a canvas the instruction "press and hold down a key" and once participants do, a second canvas is presented with the sentence "key pressed" (see pic below). All works like a charm from the second trial onwards. In the first trial however, the "press and hold down a key" canvas appears while the sound plays (in all trials it appears after the end of the sound). Does anyone see any flaw in what I did that can explain this behavior?

My workaround was to delete the sketchpad and the sampler and just use code in the inline to play the sound while a blank cavnas is shown. Works as it should. But I need to understand what was causing the problem with my initial implementation. Any ideas?
Cheers,
marios

sebastiaan

In the first trial however, the "press and hold down a key" canvas appears while the sound plays (in all trials it appears after the end of the sound).

In all other trials (except the first) it appears after the end of the sound, you mean probably? So the problem is that the sampler doesn't block on the first run (which it should if duration is set to 'sound'), while it does block on all subsequent runs. Do I understand that correctly?

mariosav

Hi Sebastian, yes...what you understood it correctly. In all trials, except the first, the sound finishes and then the instruction to "press and hold the key" appears. In the first trial, this instruction appears while the sound plays.
marios

alisdt

I've experienced something similar (with two consecutive sounds playing simultaneously), which I just reported in a separate post:

http://forum.cogsci.nl/index.php?p=/discussion/1882/sounds-in-consecutive-samplers-play-simultaneously-on-first-time-around-the-loop

Daniel

I am trying to reproduce this on a Mac and will come back to your shortly.

yrose

I just came across this post. After I had documented something similar here:

http://forum.cogsci.nl/index.php?p=/discussion/1880/bug-timingduration-issue-on-very-first-trial-of-experiment#Item_1

Thank you very much for your help with this issue --the only thing left on my way to complete my first experiment design on OpenSesame, also an amazing piece of software in several respects!

Daniel

Ok, I can confirm this issue. Is appears to be a bug in the sound sampler. The first time it plays a sound it doesn't block the experiment for the duration of the sound. All following times it plays a sound it does block as intended.

We will try to solve this as soon as we can, but in the meantime, a workaround is to place all sampler items (as linked copies) at the beginning of the experiment too, so that they play their samples (likely simultaneously) when the experiment starts, and then just show the intended behavior in the rest of the experiment.

alisdt

This doesn't seem to occur if a fixed duration is given (rather than just "sound", which admittedly is probably the most common case). So if your sounds are all the same duration, this would also serve as a workaround.

I suspect this may also point the way to the bug, I'm not too familiar with the OpenSesame code yet but I'll take a look!

sebastiaan

Hi guys,

It's indeed a bug (#401), and it will be fixed in the next maintenance release (3.0.7). For now, a workaround is the following: Add an inline_script item just before the sampler or synth item, and add the following line to the run phase (replace 'my_sampler' by the name of the sampler or synth item):

items['my_sampler'].sampler.block = True

Cheers,
Sebastiaan

alisdt

Sebastiaan, many thanks for the speedy fix! I have already applied this in isolation to our teaching lab (running 3.0.6 + a fixed sampler.pyc for this bug). It seems to work well -- this is great as I'll be teaching a session to beginners which focuses on presentation of sounds, and explaining the workaround would slow us down.

(To be clear I'm not generally in favour of ad hoc patching as it confuses bug reports on versions, but this did look like a very simple isolated change).

yrose

Adding another round of thanks here. Everything works perfectly with Sabastiaan's inline_script fix. We'll remove it from our experiment when 3.0.7 gets released.