Closed smathot closed 10 years ago
They were left out on purpose, because of the EyeLink specificity and because I didn't quite see the usefulness. After seeing people on the forum trying to use them, I agree that they might be a nice addition.
I think this will be very dodgy and asking for problems. For one, I had to communicate a lot with the Eyelink guys to get this functionality implemented with acceptable speeds. They sent me a custom pylink module which had these improvements, but never integrated these changes into their own, let´s call it, master branch, which is available to everyon. Furthermore, another colleaugue also requested changes a few months later and got sent a custom pylink module, but my changes weren´t in there, and the version number of his pylink module was also way lower than mine. In short, the way they maintain the software and various version of it seems quite messy and inconsistent. To make this work, we would have to include or make available custom pylink versions, which seems a bit far fetched.
Second, the functionality itself is very badly implemented. It is slow to send backdrops to the Eyelink computer, potentially messing up timings of experiments. Furthermore, it sometimes doesn´t work at all. On some Eyelink setups it works perfectly, on others it doesn´t and I haven´t been able to find the source of this inconsistency yet (doesn't seem to have to do with version numbers)
Third, as Edwin puts it, it is very specific, and you might indeed ask if you would like to implement such a feature for a module as pygaze which tries to be as generic as possible.
Thanks Daniel. Based on this, I guess it will be best to just point people towards the relevant pylink functions (and the sr support forum, if they run into trouble), and not include this in the pygaze API.
@dschreij added the
prepare_backdrop()
andset_backdrop()
functions tolibeyelink
, but these haven't made into pygaze.It's pretty EyeLink-specific, but still, I think it might be a nice addition.