Mastering E-Prime: Meaning of all time audit measures.

[Scott]

Perhaps I should start another thread about Task Events rather continue 
this topic here. However, I want to respond to David' post, to followup, 
clarify, and correct some information I posted earlier comparing the use of 
Task Events vs OnsetSignalData..

You're correct, David, "..Task Events can use attribute references for the 
output data, ..." and that is no different what you can do with 
OnsetSignalData. It just doesn't add much, if anything, at least for ERP 
paradigms that we tend to use, EXCEPT for a convenient way to reset the 
port after you've sent a signal. At the same time, PST missed a golden 
opportunity to add a significant MISSING feature, something that CANNOT be 
accomplished with OnsetSignals, by not implementing conditional response 
codes for Task Events. That said, I admit that I'm ready to try my first 
ERP experiment with Task Events instead of onsetSignal commands. In our 
lab, we already do post-processing of event codes, rearranging the codes 
into trials by paring each stimulus event code with a response code. With a 
(hopefully) minor teak to the program used for that step, I plan to switch 
each of the conditional response codes (sent via WritePort AFTER each 
trial), with the static response trigger sent via Task Events. That way, 
the conditional writePort code does not have to be sent in real time, but 
can be assigned to the generic, real time Task Event marker during this 
post-processing step. This doesn't help me much for paradigms we've already 
used, because I've already written a lot of  "Do While 
xxxxxxxxxx.Mask.IsPending" scripts for sending real-time response codes in 
those situations. But it will be a LOT easier for me to explain this 
method, and its simpler writePort command, to graduate students just 
learning E-Prime, than those complicated "process pending" inline scripts 
that they borrow and use (and can potentially misuse) without ever 
understanding.

Sorry if this is too much off-topic. After I've completed my first Task 
Event ERP study using this method, perhaps I'll start a new Task Event ERP 
thread with a more optimistic reevaluation.


On Monday, February 25, 2013 2:54:16 PM UTC-6, McFarlane, David wrote:
>
> Scott, 
>
> Ah yes, conditional *response* codes, that is an entirely different 
> matter from what Justine & I were discussing.  I too hoped that Task 
> Events would handle conditional response codes, but alas, no.  So for 
> that, yes, we still need to use WritePort or the like in inline code, 
> and it takes considerable coding finesse to get it to do just what we 
> want, more than we can go into here (see, e.g., discussions at 
> https://groups.google.com/d/topic/e-prime/z8PQMH1cf70 and 
> https://groups.google.com/d/topic/e-prime/7w5ajYuHqgw , as well as 
> several Knowledge Base articles about sending signals to external 
> equipment). 
>
> But back to outputting signals coincident with *stimulus* onset.  As 
> you mentioned, resetting signals at a delay after outputting them is 
> just one of the "gotchas" that I referred to, and Task Events handles 
> that very nicely.  As for *conditional* stimulus codes, as you 
> mention, Task Events can use attribute references for the output 
> data, and that seems no different to me from what you can do with 
> OnsetSignalData (but without requiring inline code).  Did I miss 
> something? 
>
> BTW, when I said that Task Events should supplant OnsetSignal..., I 
> merely meant that we users should oursleves over time abandon 
> OnsetSignal... in favor of Task Events, which does everything that 
> OnsetSignal does now, only more and better.  I did not mean that PST 
> has any evident plans to stop support for OnsetSignal, so my 
> apologies to anyone who felt alarm over the way I stated that.  I 
> suppose that users who prefer OnsetSignal may continue to do so for 
> the foreseable future.  (And note that Task Events works only with 
> EP2 Pro files.) 
> --------clip---------
> > >>  
> > >> 
> > >>-- David McFarlane, Professional Faultfinder 
>
>

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/e-prime/-/lYfhUv2QcfkJ.
For more options, visit https://groups.google.com/groups/opt_out.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20130227/149e4b60/attachment.htm>