OK, I will ask the obvious dumb question. If you
already have a program that works in
Presentation, why would you want to recreate it
in E-Prime? Although in principle E-Prime should
be able to handle this, it may require jumping
through a lot of complicated hoops, and it seems
to me that Presentation makes a better platform for this type of task.
-- David McFarlane, Professional Faultfinder
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
It looks like this 'hybrid' movie/still solution is causing more
problems than it solves. Like Presentation, you probably would like to
use some script to create/present the graphics. Unfortunately, E-Basic
only has limited support for creating graphics on the fly (text,
lines, rectangles and ellipses), and I'm not sure if your stimuli
could be drawn by those primitives. However, pre-created static
bitmaps (as movies) can be a workaround for painting more complex
graphics objects. Programming moving objects is not extremely
difficult, and if I remember correctly, there is an example available
on the pst support site
(http://www.pstnet.com/support/samples.asp?Mode=View&SampleID=8) When
the graphics objects themself change, you might run into difficulties
when the computer hardware cannot keep up with the number of required
bitmaps and desired frame rate. Using movies will probably the only
working solution in that case. I think I would include the ISI's in
the movie so it becomes a single file that can be played without
interruption. ISI durations cannot be set at runtime this way, unless
you use the technique described below.
In some cases is also possible to use an external (DLL) library to
create complex stimuli at run time (gabor patches, gradient fills,
...). Such an external library could be used to create bitmaps or
movies on the fly, which then can be loaded by eprime. However, this
requires in-depth knowledge of a programming language such as C++
because such a specific library probably doesn't exist yet. I used
this technique before to create audio files and complex bitmap
sequences. (If you have EPrime version 1, you might have a look at the
attached example. This will display a changing ellipse with a gradient
fill that can be defined at runtime in EPrime)
Best,
Paul
2011/8/18 Lisa Levinson <lml...@gmail.com>:
>> e-prime+u...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/e-prime?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "E-Prime" group.
> To post to this group, send email to e-p...@googlegroups.com.
> To unsubscribe from this group, send email to
> e-prime+u...@googlegroups.com.
If you enter a numeric (hard coded) value into the duration properties
of the wait1 to wait5 objects, you will indeed get fixed
(non-randomized) intervals. Setting the ordering property of the list
to random has no effect on this. There are several ways to get random
duration values. The easiest way (=without any inline script) is to
create a separate list and add an attribute with the interval values
you would like to use. Set the ordering of this list to random (with
or w/o replacement) and use this list as nested list in your real
trial list. The name of the attribute (i.e. 'FootageInterval') can
then be used to set the duration property in the wait objects. To make
sure EPrime picks a new value from the nested list for each wait
object you will have to use the following syntax for the durations:
[FootageInterval:0] (for duration Wait1)
[FootageInterval:1] (for duration Wait2)
etc.
Alternatively you could use a simple inline script at the start of the
trial and use the E-Basic random() function to set durations. (That
would be uniform random w/o replacement.)
Hope this helps
Paul
2011/8/24 Lisa Levinson <lml...@gmail.com>:
Um, wouldn't the E-Basic random() function result in uniform random
samples *with* replacement?
my mistake!
2011/8/25 David McFarlane <mcfa...@msu.edu>:
Of course, if Random() is based on, say, a 32-bit cyclic PRNG, then
it will repeat its sequence after no more than 2^32 = 4,294,967,296
samples (or perhaps more like 2^31 = 2,147,483,648 samples, because
E-Basic/VBA does not use unsigned integers). But that is not what I
had in mind, because we rarely use Random() to pick numbers from that
entire range.
Rather, I had in mind more common & prosaic uses such as
Random(0,99). The underlying architecture now parses the full 32-bit
range into 100 segments, with no guarantee that it will not draw
samples from the same segment until a sample has been drawn from each
segment. To the contrary, it is extremely likely in this case that
it will draw duplicate numbers within the first 100 samples. You can
see this readily if you try a scaled-down example, say, Random(0,9)
or even Random(0,2) -- I know, I just did this.
More to the point, I was thinking in terms of my understanding of the
*intent* or *specification* of the Random() function, apart from its
actual implementation. As I understand it, Random() is *meant* to
act as a die roll, not as a shuffled deck of cards. IOW, Random(1,6)
should return a random number from 1 to 6 each time, without regard
to what came before (just like a six-sided die), rather than return a
number and then remember that number and not return it again until
all other numbers have been returned (like a shuffled six-card deck).
Did I get this right now?
Best,
-- David McFarlane, Professional Faultfinder
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe@googlegroups.com.
That is indeed what happens when using the random function. (I was
just trying to talk myself out of a silly typo ;-)
A deeper understanding of the problem often raises new questions...
Purely academic off course!
I just realized that the EPrime (1.2) documentation mentions two types
of random generators: The standard visual basic functions (random,
randomize) and the E-Basic specific PRNG object. This might be
important if you use the seed value to setup your experiment to a
known state (for reproducibility and testing). The edat output file
logs a single seed value retrieved with PRNG.GetSeed(), so it would be
interesting to know if there is only one active PRNG under the hood. A
simple test shows that this is indeed the case:
PRNG.SetSeed 987654321
debug.print PRNG.GetSeed()
Randomize 123456789
debug.print PRNG.GetSeed()
will print:
987654321
123456789
cheers
Paul
2011/8/25 David McFarlane <mcfa...@msu.edu>:
Thanks for checking on the equivalence between PRNG and Randomize,
etc., and posting a very nice test. I had wondered about that
myself, and some time ago ran extensive tests to convince myself that
they all use the same underlying generator. Perhaps it is time that
I posted that as part of my "Mastering E-Prime" series. In short, I
concluded that PRNG just gathers into one E-Object all of the
functions of the standard VBA randomization functions, and that PRNG
includes a GetSeed method lacking from standard VBA. Beyond that,
which you use comes down to matter of personal programming taste or
style. I like keeping all those functions neatly organized under one
object, but I always comment that in my source code.
But of course no one should take my word for anything, so it is good
to have someone else verify this.
Best,
-- David McFarlane, Professional Faultfinder
-- David McFarlane, Professional Faultfinder