Discussion re: new PreRelease & Frame defaults for EP2

[David McFarlane]

Michiel,

I moved this discussion over here from the "clock 
and echo problem" thread.  Well...


1) For the most part, I like this change.  Let me explain...

Once I understood the actual math of PreRelease 
vs. NextTargetOnsetTime & TargetOffsetTime 
(something that PST never documented, I am 
working to correct this now), I found that using 
an ample PreRelease greatly simplified many 
coding & timing tasks.  Using an ample 
PreRelease, I can run some inline code during a 
sitmulus, and still have the next stimulus 
presented *precisely* according to the time 
settings in the stimuli themselves, without me 
having to do anything in my own inline code! -- 
none of this clumsy & sloppy "add the unused time 
to the Duration of the next stimulus" or "add a 
loop to wait for the next object onset time" 
stuff -- properly used, PreRelease takes care of 
all of that for you!  (If only PST had told us 
this from the beginning, but I digress...)

So in many of my designs now, I want to set 
PreRelease to the same value as Duration.  Sadly, 
until recently, there has been no automated way 
to do that.  So I might manually set PreRelease 
in a stimulus to the same literal value as its 
Duration, but once I turn the program over to the 
user, goodness help us if they later go and 
change the Duration!  (One lab has a sign up 
reminding users to always change PreRelease to 
the Duration!)  So I wanted a "(same as 
duration)" option for PreRelease, and was very 
glad when I saw it in EP2.0.10.182.

But what about making this the new 
default?  Well, IMO, more often than not, this is 
what the user really wants, or at least ought to 
want.  Now, I say "more often than not", but 
maybe not much more often.  Changing this default 
will cause some new problems, while solving a lot 
of other problems, some that users don't even 
know that they have.  Actually, the new default 
would have caused a *lot* of problems, but PST 
has also worked hard to implement complementary 
changes to avoid those (e.g., 
FeedbackDisplay.ProcessInputObjectPendingInputMasks, 
Procedure.ProcessPendingInputMasks, StopAfterMode 
for Sound & Movie object; note also that PST has 
now deprecated ClearAfter, as this will not work 
well with the new default value of PreRelease -- 
an overdue move, IMO).  These changes do not 
solve everything, but I really believe that the 
net effect will be to let most users get the most 
out of E-Prime without having to think so hard 
about PreRelease, and in the long run this will 
solve more problems than it causes.  But we do 
have to get used to thinking along these new 
lines, and taking control of the new time 
programming options that go along with the new default for PreRelease.


2) I may not be typical here.  I write a *lot* of 
small demo programs to explore & figure out 
E-Prime (I mean, a ***lot***), and I almost never 
really want my stimuli to completely fill the 
screen.  Often this poses no problem.  But all 
too often, when I have long text passages to 
display, they reach right to the edges of the 
display, and that looks sloppy.  Then I have to 
go and manually adjust the frame size down to 
provide some margins, etc.  A default frame size 
of 75% each way will just spare me that trouble, 
so this change actually fulfills another item on 
my own E-Prime wish list.  But in this case, I 
agree this change may not suit others so well.


But with that all said, note that, if you develop 
programs using the Professional file format, then 
you may customize the Toolbox defaults as you 
like, including PreRelease, Width, Height, etc. 
(see 
http://www.pstnet.com/support/kb.asp?TopicID=4896 
).  Save your changes to a template file, and 
then whenever you start a new program from that 
template, voilà, every Toolbox item uses your 
preferred defaults!  So, no need to wait for PST 
to change the defaults back, you can do this 
yourself (if only on a user-by-user basis)!

Of course, this works only for files using the 
Pro format, which brings up another issue.  Long 
ago I advised everyone to use EP2 Pro, but to 
stick to the non-Pro file format for the sake of 
widest compatibility with colleagues.  But 
starting with EP2.0.10.182, Pro offers many 
features too good to pass up, so I am reversing 
my advice.  From now on, all *research* users 
should still spend the extra money to buy Pro, 
and then develop everything using the Pro file 
format.  That will break compatibility with 
colleagues who were too cheap to buy the Pro edition, but that can't be helped.


So, as I belive I said in earlier thread, overall 
I am very excited with all the improvements that 
came with EP2.0.10.182 -- it looked just as if 
they acted on all my complaints from over the 
years!  But I still have to go over these in more 
depth, and will have to see how these changes 
work in practice.  In fact, some of these changes 
already break some of the exercises in my online training videos :(.

Best,
-----
David McFarlane
E-Prime training 
online:  http://psychology.msu.edu/Workshops_Courses/eprime.aspx
Twitter:  @EPrimeMaster (twitter.com/EPrimeMaster)


At 9/7/2012 09:48 AM Friday, Michiel Sovijarvi-Spape wrote:
>Hi David,
>Slightly off-topic, what do you think of this default? I thought myself it
>was rather strange of PST to change, suddenly after all these years (and
>dozens of pre-release versions, with none having these defaults AFAIK) to:
>1) set pre-release to duration by default, so that inline code after the
>object is executed before the end of the object (not very transparent coding
>at all - one wouldn't be able to see this from the structure)
>2) set textdisplays to 75% by default. I can see how they like to show off a
>feature that has been there since forever and can really be extremely useful
>and which people often fill in with needless extra slides. But I noticed,
>when I last made a presentation about e-prime, that I very often had to say
>"oh, yeah, sorry, forgot to turn width to 100%", until I just made an
>unreferenced object which I copied whenever I needed a new "blank" display.
>It's almost like Microsoft would suddenly just publish your calendar without
>asking to the world (with option somewhere hidden to not do this): a useful
>feature, to be sure, one which few people probably use, and maybe not use
>for simple reason that it's a bit hidden in the GUI. But to think the
>solution is it should be on by default? Then again, maybe they have some
>better reason that eludes me?
>
>I hope they can change it back, it's pretty annoying.
>
>Best,
>Michiel

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.