I think I can suggest an approach that will give you the result you desire.
I will describe a way to deliver a “raise lines” event at the start of an image presentation, and then lower the lines during the variable-length picture stimulus presentation.
For the purposes of my explanation, I will use LONGER durations, so that when I show you an example, the differences in durations will be noticeable, and also so that the duration of the pulse will be clearly noticeable.
For this example, say that we want an image to vary onscreen from 2 seconds to 5 seconds. Let’s also say that we want each pulse to last exactly one second.
The first thing to note is that we must account for the fixed pulse duration when setting up our image duration variable. Each prospective variable value should be set to: [ desired-image-duration MINUS fixed-pulse-duration ].
So, for example, since we want the image to vary from 2 seconds to 5 seconds, we will vary the duration variable from 1 second to 4 seconds. (The reason will be clear soon.)
Then, we will create FOUR events in SuperLab. These events will be:
- raise lines
- show the image for 1 second
- lower lines
- (continue to) show the same image for a variable duration
For the “raise lines” and “lower lines” event, we want the event to end immediately after it’s presented. For the first picture event, we end the event after 1000 ms. For the second picture event, we set it to end after a trial variable, which is a variable we will set up as described earlier – with values varying between 1 and 4 seconds.
Also, for both picture events we should edit the Picture event settings to REMOVE the checkmark next to “erase screen before presenting stimulus”. This way, with no screen erasure between the two events that use an identical image, there is no way to notice visually that this is actually two separate picture events.
Here is a short (4 minute) video showing how I set this up: http://screencast.com/t/yFvFcZh3X
(Note that you can PAUSE the video at any point if there is a SuperLab menu that I might have closed too quickly and you need to re-read it.)
I also made a video showing how my demo experiment actually runs. However, because you cannot actually see my digital io card that I am testing with that shows LED bulbs lighting up in conjunction with the “raise lines” event, I took the liberty of inserting more on-screen text into my experiment to give an on-screen text indicator of when the pulse is happening. You can view that here: http://screencast.com/t/Ss72KAGCUU9a
FURTHER POSSIBLE MODIFICATIONS:
My first example places the “raise lines” event PRIOR to the picture event. It is also possible to reverse that ordering. Even on multi-core machines, it is virtually impossible to have true instantaneous synchronization between the picture and the io lines, due to the operating system, hardware drivers, USB and/or other connectors, and screen/monitor refresh rates. Therefore, if the “raise lines” comes before the picture event, then any minor discrepancies will tend towards drawing the picture slightly after raising the lines. Reversing the order of the events will tend towards starting the pulse just slightly after drawing the image.
I suggest that you try both sequences. Your particular needs will dictate whether lines-then-picture or picture-then-lines is best.
To try the reverse ordering:
Move the event “image for length of pulse” up ABOVE (prior/before) the “raise lines” event. Then set “image for length of pulse” to end "immediately after the event is presented. Then, just after the “image for length of pulse” event and PRIOR to the “raise lines” event, insert an ISI event with a duration of 1000 ms (or whatever duration is needed for the pulse). In other words, the ISI goes BETWEEN “image for length of pulse” and “raise lines”.