<br>Dear Scott and David,<br><br>I was just reading your complaints about lack of  conditional response codes in task events. I wanted to let you know that<br>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<br>and no response). Take a look at their Paradigm Elements for Ports, which is what we're using to interface Paradigm with our Neuroscan:<br><br>http://www.paradigmexperiments.com/Elements/Ports/Paradigm-Elements-for-Ports.html<br><br>Just a thought. <br><br><br>On Wednesday, February 27, 2013 3:54:01 PM UTC-6, Scott wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">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..<br><br>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.<br><br>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.<br><br><br>On Monday, February 25, 2013 2:54:16 PM UTC-6, McFarlane, David wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Scott,
<br>
<br>Ah yes, conditional *response* codes, that is an entirely different 
<br>matter from what Justine & I were discussing.  I too hoped that Task 
<br>Events would handle conditional response codes, but alas, no.  So for 
<br>that, yes, we still need to use WritePort or the like in inline code, 
<br>and it takes considerable coding finesse to get it to do just what we 
<br>want, more than we can go into here (see, e.g., discussions at 
<br><a href="https://groups.google.com/d/topic/e-prime/z8PQMH1cf70" target="_blank">https://groups.google.com/d/<wbr>topic/e-prime/z8PQMH1cf70</a> and 
<br><a href="https://groups.google.com/d/topic/e-prime/7w5ajYuHqgw" target="_blank">https://groups.google.com/d/<wbr>topic/e-prime/7w5ajYuHqgw</a> , as well as 
<br>several Knowledge Base articles about sending signals to external equipment).
<br>
<br>But back to outputting signals coincident with *stimulus* onset.  As 
<br>you mentioned, resetting signals at a delay after outputting them is 
<br>just one of the "gotchas" that I referred to, and Task Events handles 
<br>that very nicely.  As for *conditional* stimulus codes, as you 
<br>mention, Task Events can use attribute references for the output 
<br>data, and that seems no different to me from what you can do with 
<br>OnsetSignalData (but without requiring inline code).  Did I miss something?
<br>
<br>BTW, when I said that Task Events should supplant OnsetSignal..., I 
<br>merely meant that we users should oursleves over time abandon 
<br>OnsetSignal... in favor of Task Events, which does everything that 
<br>OnsetSignal does now, only more and better.  I did not mean that PST 
<br>has any evident plans to stop support for OnsetSignal, so my 
<br>apologies to anyone who felt alarm over the way I stated that.  I 
<br>suppose that users who prefer OnsetSignal may continue to do so for 
<br>the foreseable future.  (And note that Task Events works only with 
<br>EP2 Pro files.)
<br>
--------clip---------<br>> >>  <br>> >>
<br>> >>-- David McFarlane, Professional Faultfinder
<br>
<br></blockquote></blockquote>

<p></p>

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