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

[neuro2]

Dear Scott and David,

I was just reading your complaints about lack of  conditional response 
codes in task events. I wanted to let you know that
we're using a program called Paradigm in our ERP lab that does in fact have 
this feature (you can specify unique codes for correct, incorrect
and no response). Take a look at their Paradigm Elements for Ports, which 
is what we're using to interface Paradigm with our Neuroscan:

http://www.paradigmexperiments.com/Elements/Ports/Paradigm-Elements-for-Ports.html

Just a thought. 


On Wednesday, February 27, 2013 3:54:01 PM UTC-6, Scott wrote:
>
> 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/-/34UPAv1sBPsJ.
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/20130301/0cff1ad3/attachment.htm>