agen judi bola , sportbook, casino, togel, number game, singapore, tangkas, basket, slot, poker, dominoqq, agen bola
. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 50.000 ,- bonus cashback hingga 10% , diskon togel hingga 66% bisa bermain di android dan IOS kapanpun dan dimana pun. poker , bandarq , aduq, domino qq , dominobet
. Semua permainan bisa dimainkan hanya dengan 1 ID. minimal deposit 10.000 ,- bonus turnover 0.5% dan bonus referral 20%. Bonus - bonus yang dihadirkan bisa terbilang cukup tinggi dan memuaskan, anda hanya perlu memasang pada situs yang memberikan bursa pasaran terbaik yaitu http://184.108.40.206/
Bola168. Situs penyedia segala jenis permainan poker online kini semakin banyak ditemukan di Internet, salah satunya TahunQQ merupakan situs Agen Judi Domino66 Dan BandarQ Terpercaya
yang mampu memberikan banyak provit bagi bettornya. Permainan Yang Di Sediakan Dewi365 Juga sangat banyak Dan menarik dan Peluang untuk memenangkan Taruhan Judi online ini juga sangat mudah . Mainkan Segera Taruhan Sportbook anda bersama Agen Judi Bola
Bersama Dewi365 Kemenangan Anda Berapa pun akan Terbayarkan. Tersedia 9 macam permainan seru yang bisa kamu mainkan hanya di dalam 1 ID saja. Permainan seru yang tersedia seperti Poker, Domino QQ Dan juga BandarQ Online
. Semuanya tersedia lengkap hanya di ABGQQ. Situs ABGQQ sangat mudah dimenangkan, kamu juga akan mendapatkan mega bonus dan setiap pemain berhak mendapatkan cashback mingguan. ABGQQ juga telah diakui sebagai Bandar Domino Online
yang menjamin sistem FAIR PLAY disetiap permainan yang bisa dimainkan dengan deposit minimal hanya Rp.25.000. DEWI365 adalah Bandar Judi Bola Terpercaya
& resmi dan terpercaya di indonesia. Situs judi bola ini menyediakan fasilitas bagi anda untuk dapat bermain memainkan permainan judi bola. Didalam situs ini memiliki berbagai permainan taruhan bola terlengkap seperti Sbobet, yang membuat DEWI365 menjadi situs judi bola terbaik dan terpercaya di Indonesia. Tentunya sebagai situs yang bertugas sebagai Bandar Poker Online
pastinya akan berusaha untuk menjaga semua informasi dan keamanan yang terdapat di POKERQQ13. Kotakqq adalah situs Judi Poker Online Terpercaya
yang menyediakan 9 jenis permainan sakong online, dominoqq, domino99, bandarq, bandar ceme, aduq, poker online, bandar poker, balak66, perang baccarat, dan capsa susun. Dengan minimal deposit withdraw 15.000 Anda sudah bisa memainkan semua permaina pkv games di situs kami. Jackpot besar,Win rate tinggi, Fair play, PKV Games
You were almost there: use
[correct] = 0instead.
If you use the
correctvariable, this will indeed be a binary approach. However, you could also employ the same approach, but with a different variable. You could use the
responsevariable instead. Then the Run if for a correct response would be
[response] = [goodresp](replace "goodresp" with the variable in which you define the correct response). After a timeout, the response will be None, so use the following in as a Run if statement:
[response] = None. Finally, for an incorrect response, use
[response] != [goodresp] and [response] != None(the term '!=' means "does not equal").
Does this solve your problem?
PS: I'll pass on your compliments to the main developer of the parallel_port_trigger plug-in. I'm sure he'd be delighted that it proves useful to you!
Oops, this was a double post.
Thanks for your quick reply. Especially, your suggestion using the
responsevariable did the trick for me. As regards what should be typed into Run if I always mix up the python syntax with the OpenSesame gui syntax (e.g.
=) and that often gives me a hard time figuring out where the error is ;-)
I have a follow up question/problem:
In the respective sequence I have placed the three parallel_port_trigger items (correct, false, timeout) after a keyboard response item that defines a timeout of
2000ms. Each parallel_port_trigger item then defines duration as
2ms in the case of timeout.
This does not work correctly: I always have to press the allowed keys twice to see the trigger appearing in the ongoing EEG recording.
I guess the problem lies in the duration/timeout definitions. But what does the right job here?
Thanks for your help.
Excellent, very good to hear that you've fixed the conditional statements.
parallel_port_plugin: The timeout of the former should be the response timeout that you wish to use, and the Duration of the latter should simply be a value in milliseconds. The logic of this is that the
keyboard_responsewill take care of the keyboard (registering either a response or a timeout), whereas the trigger should simply be a short signal (if you set the Duration to 'keypress', the
parallel_port_triggerwill actually wait for a keypress as well, on top of that of the
By no means should you use 'keypress' as the Duration of the
parallel_port_trigger. We added that option during debugging and we forgot to take it out, I'm afraid. We've fixed that very recently, though, so if you download the newest version of the plug-in from GitHub (go to this page, and click on the button labelled Download ZIP on the right), you should be fine. Also, note that the fact that the keyboard response option was still in there, only made that you could set the Duration to 'keypress', and that the trigger duration could be interupted by a keypress (but with the short durations that these triggers usually have, this is very unlikely to be a problem). Sorry for the confusion!
Did that do the job?
Thanks, that does the job. I have (git) pulled the most recent version of the plugin (the keypress option is still mentioned in the inline help) and used
keypressonly in the keyboard response item (defining also a timeout of 2000ms) and set the duration of the parallel_port_trigger item to 2 ms (as I plan to record EEG with a sampling rate of 500Hz).
Now everything works as expected but still there are two issues:
A small issue:
The Debug Window tells me "The local version of pyparallel could not be loaded. Check if the file is present and if the file permissions are correct."
And a bigger one:
If I simulate a participant pressing the response key too early, I get unexpected triggers sent out: 46 for too early correct answers and 56 for too early wrong answers. I have never defined nor used these numbers as trigger codes anywhere, though.
The small issue you mention is simply a warning that no local version of pyparallel could be found. To compensate for this, the onboard version will automatically be used.
The bigger issue is quite an interesting one, that I can't quite figure out remotely. Could you maybe upload a screenshot of your
parallel_port_trigger? Also, could you define what you mean by 'pressing too early'? Is this before the
The relevant part of the trial is as follows:
I can replicate the thing exactly. It takes me a while to get into the exact timing, but after a while I can thoroughly produce it:
It occurs when I press a response key twice with the second key press immediately following the first one (like a double key press) and shortly before the question mark (maybe the first is before and the second right behind the sketchpad item). The first key press is immediately before the question mark becomes visible (the sketchpad just flashes shortly). Under these circumstances I get 46 or 56 as triggers. Any following responses within that trial are blocked. That's weird.
I'm using a Neuroscan Nuamps amplifier with SCAN 4.5/Acquire as recording software.
OpenSesame is run under Xubuntu 13.10 here.
Hope we'll find a solution soon.
Seems perfectly fine. And you have the latest version from here?
I'll ask the main developer if maybe he can shed some light on this. Also, @sebastiaan, any tips?
Yes, it's the most recent version.
Already up to date.
I think I'm getting closer:
It seems that the
firstfinal (leftmost) bits are missed.
correct trigger when pressing early:
incorrect trigger when pressing early:
...and indeed if I change the correct trigger to
01101111), I get:
It's always the first 1 that misses.
To be clear: It's hard to get the exact timing for this. It occurs only when I press the answer button twice immediately before the question mark appears.
However, this can happen every once in a while during an experiment. So one should at least be aware of that certain triggers might better be left out and not be used for any other coding.
Of course another solution would be more satisfactory :-(
Hi Johannes (and Edwin),
I think the problem is related to the binary-or ghost triggers that we discussed a year-or-so ago. Basically, my guess is that the following happens.
First you send a trigger, say 110 (or binary
01101110), followed by another trigger of value 0 (
00000000). When these two triggers follow each other too rapidly, they get intermixed, and the final bits of the first trigger get replaced by the final bits of the second trigger (final meaning 'highest', so on the left). In your case, this results in the final two bits of 110 (i.e.
01) being replaced by the final two bits of 0 (
00), resulting in 46 (
The duration of your trigger (i,e. the interval between trigger 110 and trigger 0) is very short (2 ms) and is probably pushing the limits of what your setup can handle. My guess is that when you rapidly press keys beforehand, this interferes just the tiniest bit with the timing, thus causing the mixups to occur more frequently. Note that the plug-in actually polls the keyboard while sleeping, which may be why this happens (incidentally, this polling may not be a terribly good idea, at least for short intervals).
So I doubt that the problem is related to the key presses per se. They just make it more visible.
Practically speaking, your problem will likely go away if you a) set the trigger duration to a higher value, or b) set the duration to zero (i.e. infinite) and simply reset the trigger by sending a 0-value trigger at the start of each trial.
I think it might be worthwhile to test this issue in a bit more detail. This could be done very easily. In a script, simply send a 255 trigger, sleep for a variable delay, and have it followed by a 0 trigger. I suspect that at short delays, you should start to lose progressively more bits, resulting first in a 127 (
01111111), then a 63 (
00111111), and maybe even a 31 (
00011111) at extremely short delays.
You can also do the converse, sending very brief 0 triggers, followed by a sustained 255. This is also important, because based on your previous issue there appears to be an asymmetry between turning bits on and off.
Once we get to the bottom of this, we could see (maybe Bob could do a few quick tests?) whether it's specific to your set up, or whether the same happens on other set ups as well. If this is the case, we should inform people about the risk.
Thank you for your quick reply, Sebastiaan.
Indeed, the ghost-trigger thing was what put me on the right track. :-?
I have tested the whole thing now with a minimum trigger length of 4ms (I didn't test 3ms, though) and it seems that I cannot produce these unwanted triggers any more.
I have more triggers defined than just the mentioned response triggers. At a first try I just set the response triggers up to 4ms while leaving other triggers at 2ms. This was even worse because now my "hammering" on the keyboard resulted in some of the 2ms triggers beeing skipped -- This might be an indicator that you are right in assuming that the problem is more related to trigger length. However, as I said before, if all triggers are at 4ms and above, everything seems fine.
Regarding your proposed script, I would need some further advice on how to program this for a Linux machine (I switched to Xubuntu on the presentation PC recently). The scripts I have at hand will only work for Windows as they use dlportio. For sending triggers on Linux, I entirely rely on the plugin by now. But if someone could tell me how to "talk" to the parallel port on Linux, I would be willing to run these tests.
On the shortness of the trigger:
I remember when we were investigating that ghost-trigger problem, I also talked to a support technician from BrainProducts (as I used a BrainAmp in Marburg). And he told me, that the trigger length would be related to the sampling rate at which you record your EEG: for a recording at 500Hz sampling rate (one data point every 2ms) the minimum trigger length should be 2ms, for a recording at 1000Hz (one data point every 1ms) the minimum trigger length should be 1ms.
Well, maybe that's not valid for the NuAmps I am working with here in Calgary. It is capable of recording at a sampling rate up to 1000Hz and that's what I am currently testing with. So normally, 1ms should be fine and I used 2ms, but even that seems to be too short???
I do not know though, how the parallel_port plugin works internally. Obviously it sends out the 0 triggers to avoid the ghost triggers automatically. Or am I wrong here? Maybe there is some issue with the delay with which these 0 triggers are sent out after the actual event trigger?
Or is it related to the NuAmps recording with 24bit? There is also an option for recording with 32bit... Well, I am currently digging myself through the NeuroScan documentation...
I cannot test it here, because I don't have a parallel port on my machine, but something like the script below should do the trick. See the code comments for details.
Yes, so apparently some part of the chain is not fast enough. This could be the script, the rate at which the triggers are sent, or the rate at which the triggers are received and processed. But what exactly is causing the problem is difficult to say.
The parallel port is, as far as I know, always 8 bits, with each bit actually corresponding to a physical pin in the connector. So the bitrate of the device probably refers to something else, maybe the resolution with which the voltages are recorded.
Hi Sebastiaan and Edwin,
I have tested out the minimal trigger length with Sebastiaan's script (thank you very much for providing it!).
To make the
import parallelppdevwork, I had to add the following lines before it:
I tested with 24bit and 32bit recording and then imported the .cnt-files to EEGLAB/ERPLAB and created event list files. I put them on Google Drive (triggerdist.txt for 32bit and triggerdist24.txt for 24bit recording). Here's the link. The relevant column is ecode (event code).
Bitrate seems to be a minor issue (though it seems that the 32bit recording is a little better/shows less distorted triggers).
Here are the results:
Throughout the first 100 cycles there are
63triggers appearing, i.e. a 1ms trigger duration is too short. However, after these 100 cycles only correct
I constantly loose the last two bits, since only
So this only explains part of the problem, as I originally used a minimum trigger length of 2ms which should be fine according to this test.
Well, the most important thing is that you got it working for your experiment. But apparently the problem is not simply due to the short delay then. I'll pass this on to Bob, the developer of the parallel port plug-in, to see what he thinks.
Hi Johannes, Sebastiaan and Edwin,
I did not test the minimal duration for a trigger to be fully processed. For our experiments sending triggers with a duration of 100 ms is adequate enough. According to your data it seems the individual bits are processed in a serial way. Gonna check this next week with a 2000 Hz Biopac.
I am wondering why you need the duration to be 1 or 2 ms if you are working with human responses. Would a duration of 100 ms not be good enough?