Cross-platform functionality?

[iandol]

Hi Dee,

First off thank you for this wonderful tool. I recently bought a couple of Spectrum Pro's — but when I started to code a wrapper around the Pro SDK, became really frustrated. On my Eyelink, I'm used to being able to "peek" at the current eye position, while having everything synced and saved to EDF files retrieved at the end of the experiment. The Pro SDK consumes data every time you want to check eye position, then you end up with unwieldly and poor performing arrays of GazeData objects you have to manually store in an already busy PTB loop, really badly designed (and if you use GazeData, terribly performing, ~3ms to fetch within each flip loop, unworkable at e.g. 8ms IFI).

BUT, I want to use Linux (strongly encouraged by Mario of course, but having worked with windows 10 over the last couple of weeks, I've had far better performance and reliability with Ubuntu on the same machines). I see you are using C DLL files, but I'm not sure if it could be made to work with the linux equivalents?

Thanks for any advice!

[dcnieho]

Thanks for the kind words! Exactly the same problem is why i wrote my own mex file as part of Titta in the first place indeed.

Linux is very much planned, i just need to figure out how to build a mex file on linux. Same goes for working with Octave (in case you're using that). Haven't looked into it yet, shouldn't be too hard. Thing is that i am not using the mex function on Windows, so would take a bit more effort to port.

Do you happen to have experience with that?

Cheers, Dee

On Fri, Aug 9, 2019, 12:59 Ian Max Andolina notifications@github.com wrote:

Hi Dee,

First off thank you for this wonderful tool. I recently bought a couple of Spectrum Pro's — but when I started to code a wrapper around the Pro SDK, became really frustrated. On my Eyelink, I'm used to being able to "peek" at the current eye position, while having everything synced and saved to EDF files retrieved at the end of the experiment. The Pro SDK consumes data every time you want to check eye position, then you end up with unwieldly and poor performing arrays of GazeData objects you have to manually store in an already busy PTB loop, really badly designed (and if you use GazeData, terribly performing, ~3ms to fetch within each flip loop, unworkable at e.g. 8ms IFI).

BUT, I want to use Linux (strongly encouraged by Mario of course, but having worked with windows 10 over the last couple of weeks, I've had far better performance and reliability with Ubuntu on the same machines). I see you are using C DLL files, but I'm not sure if it could be made to work with the linux equivalents?

Thanks for any advice!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGO5OHRZYAYLKPT3MM3QDVEXJA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HEL3WPA, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGMQDUXJ35ZED7TP2YLQDVEXJANCNFSM4IKS6AEA .

[iandol]

Hi Dee, sadly I don't, I'm not a C/C++ coder, so only really know how to follow instructions to run make 😢... I can try to build the C API files for linux, but the question is whether the way you call them is in your mex files is compatible across OSes?

Of course @kleinerm is the one who would know, he may be able to give some pointers. I don't yet really understand what would be required, but if we can formulate a more precise question then hopefully Mario could point us in the right direction...

I am trying to hire programmers or find someone who will work under contract, but finding people with the right experience set isn't so straight-forward...

OK, let me have a go at building the C SDK, then I'll feed back and we can try to better define the problems we may encounter...

Cheers, Ian

[dcnieho]

Hi Ian (and Mario),

No worries, I'll try to figure it our first. While on windows the whole thing is built as a separate lib that is then consumed by a matlab wrapper, there is no real need to do so. I'll try compiling it all at once through a mex call and see what happens. Simply haven't tried yet.

Cheers, Dee

On Sat, Aug 10, 2019, 03:29 Ian Max Andolina notifications@github.com wrote:

Hi Dee, sadly I don't, I'm not a C/C++ coder, so only really know how to follow instructions to run make 😢... I can try to build the C API files for linux, but the question is whether the way you call them is in your mex files is compatible across OSes?

Of course @kleinerm https://github.com/kleinerm is the one who would know, he may be able to give some pointers. I don't yet really understand what would be required, but if we can formulate a more precise question then hopefully Mario could point us in the right direction...

I am trying to hire programmers or find someone who will work under contract, but finding people with the right experience set isn't so straight-forward...

OK, let me have a go at building the C SDK, then I'll feed back and we can try to better define the problems we may encounter...

Cheers, Ian

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGOFSKU34UUZGVZ64VLQDYKZLA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ADHZI#issuecomment-520106981, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGLQ5USJRQK6REC4KDDQDYKZLANCNFSM4IKS6AEA .

[iandol]

@dcnieho — OK if there is anything I can do to help testing, let me know!

[dcnieho]

Hey,

Got things to mostly work on Linux! In the end without needing a fancy new compiler, there was only one C++ feature left that default GCC 7.4.0 on Ubuntu 18.04 doesn't support. So all good.

There are some cosmetic things left (wrong cursors are used as they have different IDs on Windows and Linux, I'll fix that) and one bigger thing: on Linux the Tobii systems and PTB use different clocks to get system time. So all the timebased peek and consume functions don't work (return no data as time range completely off) and also message timestamps will be useless. Peek and consume for specific number of samples are fine. One consequence of this is that there are no eye images in the setup interface right now. As it seems Tobii made a nonstandard choice of clock, i have reached out to them.

In the meantime, there is a working compiled mex file in the compileWithMex branch, if you want to get started for as far as possible.

Octave support will not happen with 5.1, as it has bugs regarding function handles to class members, which i use extensively. It appears (untested by me) that these bugs were fixed mere weeks after the 5.1 release, but we buy nothing for that of course...

Cheers, Dee

On Mon, 12 Aug 2019, 06:39 Ian Max Andolina notifications@github.com wrote:

@dcnieho https://github.com/dcnieho — OK if there is anything I can do to help testing, let me know!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGIJ3R5XIUKJ4U2DSOLQEDSONA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BRVYY#issuecomment-520297187, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGJ5GPDCJXG7WRDT3E3QEDSONANCNFSM4IKS6AEA .

[iandol]

Great news! Different system clocks across OSes is a pain, I hope Tobii will come up with workable solution... I have mentioned Titta in some of my support cases with them. An unpaid scientist developed an API an order of magnitude better than their paid developers have ;-) They should employ you as an advisor! 😎😎😎

As I use also use classes in MATLAB extensively (including property validation, events etc.), I never tried to get any of my code on Octave. It must be hard for Octave developers as MATLAB is a moving goalpost, every release tweaks the programming features, including the OOP interface...

[dcnieho]

Thanks man! Perhaps a good idea for Tobii indeed.

It seems that/I hope that problems using function handles to class methods is the only thing blocking Titta from running on Octave. Else i may drop that idea forever as well. We'll see.

On Sun, Aug 25, 2019 at 12:51 PM Ian Max Andolina notifications@github.com wrote:

Great news! Different system clocks across OSes is a pain, I hope Tobii will come up with workable solution... I have mentioned Titta in some of my support cases with them. An unpaid scientist developed an API an order of magnitude better than their paid developers have ;-) They should employ you as an advisor! 😎😎😎

As I use also use classes in MATLAB extensively (including property validation, events etc.), I never tried to get any of my code on Octave. It must be hard for Octave developers as MATLAB is a moving goalpost, every release tweaks the programming features, including the OOP interface...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPRWJHMOCIR7X6THPTQGJP3ZA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CRCSY#issuecomment-524620107, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGOEWBAKSA3RLUY7MH3QGJP3ZANCNFSM4IKS6AEA .

[kleinerm]

On Sun, Aug 25, 2019 at 1:04 PM Diederick C. Niehorster < notifications@github.com> wrote:

Thanks man! Perhaps a good idea for Tobii indeed.

Cool work, Dee!

It seems that/I hope that problems using function handles to class methods is the only thing blocking Titta from running on Octave. Else i may drop that idea forever as well. We'll see.

The (nested?) function handles limitation seems to be the main stopper for many things. I remember trying Ian's Opticka on Octave a year ago and most of the classdef stuff worked, but limitations with function handles were the stopper for that as well. Also some of the issues we have in the bug tracker are caused by incomplete nested function handle support. I remember reading something on their forum about somebody working on improvements, but progress seems to be slow. And Octave in general doesn't do more than one feature release a year - in good years. I guess wait and see is the game...

Wrt. clocks, have a look at GetSecs('AllClocks'):

http://psychtoolbox.org/docs/GetSecs-AllClocks

it returns both the gettimeofday() wall-time clock aka CLOCK_REALTIME, which is used by PTB's by default, and the CLOCK_MONOTONIC. If Tobii uses CLOCK_MONOTONIC then it should be easy to remap timestamps from PTB <-> Tobii with some simple addition and that function has everything you need for that.

PTB uses CLOCK_REALTIME on Linux for historical reasons - support for CLOCK_MONOTONIC didn't exist around 2006'ish when i did the port - or at least i wasn't aware of it. It's on my low-priority todo list to sometime switch GetSecs et al. over to CLOCK_MONOTONIC, as that in theory would be a tiny bit more accurate and not subject to NTP adjustments. Atm. most Linux native timing api's do operate in CLOCK_MONOTONIC and i have to remap internally. In practice the remapping error is at < 10 microsecond level at best, usually non-existent, and changing timebase sounds like something that needs to be done with a lot of testing to make sure that all mex files and 3rd party libraries still properly talk to each other. Just to say if Tobii uses CLOCK_MONOTONIC then your problem should be easy to fix and in some way they made the optimal choice of clock.

-mario

On Sun, Aug 25, 2019 at 12:51 PM Ian Max Andolina notifications@github.com

wrote:

Great news! Different system clocks across OSes is a pain, I hope Tobii will come up with workable solution... I have mentioned Titta in some of my support cases with them. An unpaid scientist developed an API an order of magnitude better than their paid developers have ;-) They should employ you as an advisor! 😎😎😎

As I use also use classes in MATLAB extensively (including property validation, events etc.), I never tried to get any of my code on Octave. It must be hard for Octave developers as MATLAB is a moving goalpost, every release tweaks the programming features, including the OOP interface...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPRWJHMOCIR7X6THPTQGJP3ZA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CRCSY#issuecomment-524620107 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AANUOGOEWBAKSA3RLUY7MH3QGJP3ZANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNUYDWBCCIIKUWEF7VTQGJRNHA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CRJOA#issuecomment-524620984, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXMNX2OO2YYEU5XDDGUWTQGJRNHANCNFSM4IKS6AEA .

[dcnieho]

Thanks @kleinerm!

I've searched through the Octave bug tracker, and it seems they're making a push now to fix all kinds of function handle things. Its not nested functions this time, just handles to class methods. We'll see where it goes, i am in no rush.

Regarding time, thanks a lot for chiming in! I have tried that GetSecs call, but got the same time for both return values:

[a,b,c] = GetSecs('AllClocks')
a =
   1.5668e+09
b =
   1.5668e+09
c =
   9.5367e-07

This is on an up-to-date Ubuntu 18.04.3 with HWE (so kernel 5.0.0-25-generic) and PTB installed through DownloadPsychtoolbox. I first installed through Neurodebian, but they don't have the 3.0.16 series yet, which i need. Is GetSecs('AllClocks') working correctly?

When you remap internally, do you do that with an offset determined once, or do you periodically resync the two clocks?

[dcnieho]

Tobii said that they indeed use CLOCK_MONOTONIC.

@kleinerm if i understand you correctly, most functions generating timestamps (by which i think of Screen Flips and PsychHID use APIs that use CLOCK_MONOTONIC) internally that you then map to gettimeofday() times? Perhaps a smooth transition would be to add a Screen Preference to use CLOCK_MONOTONIC instead. I'd be happy to help out.

But if you prefer, I can map as well (am I using GetSecs('AllClocks') correctly, and is it returning expected output?)

[kleinerm]

Oh i was mistaken about my own code. The GetSecs('AllClocks') returns the same timestamp for both GetSecsTime and WallClock return args, because GetSecs == gettimeofday wall clock. I guess i'll need to extend GetSecs with another return argument 'otherClock' or something to deal with this :/ -- As i'm moving flats this week, i likely won't have much time or internet connectivity to do this now - In fact, today is the scheduled data of Internet shutdown at my old flat, so i expect to drop off the net any minute now.

On Mon, Aug 26, 2019 at 12:13 PM Diederick C. Niehorster < notifications@github.com> wrote:

Tobii said that they indeed use CLOCK_MONOTONIC.

Makes sense, it is the best choice for precision timestamping nowadays.

@kleinerm https://github.com/kleinerm if i understand you correctly, most

functions generating timestamps (by which i think of Screen Flips and PsychHID use APIs that use CLOCK_MONOTONIC) internally that you then map to gettimeofday() times? Perhaps a smooth transition would be to add a Screen Preference to use CLOCK_MONOTONIC instead. I'd be happy to help out.

Yes, display and audio timestamps, as well as HID input device timestamps and various other subsystem timestamps are nowadays in CLOCK_MONOTONIC by default, so PTB remaps internally to gettimeofday time, with a maximum allowed remapping error of 20 usecs if i remember correctly, but in practice the remapping is almost always/usually microsecond accurate so we don't pay a prize in accuracy, just in a tiny bit of overhead, but what is a sub-microsecond between friends?

-mario

But if you prefer, I can map as well (am I using GetSecs('AllClocks') correctly, and is it returning expected output?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNTOPKZZZOCY7LDIDGLQGOUF5A5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5D6GQQ#issuecomment-524804930, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXMNQAUMVNEYOBL6CFCRTQGOUF5ANCNFSM4IKS6AEA .

[dcnieho]

Good luck with the move!

I guess an interface like this would possibly make sense: [GetSecsTime , WallTime, wallSyncErrorSecs, MonotonicTime, monotonicSyncErrorSecs] = GetSecs('AllClocks')

where wallSyncErrorSecs is error estimate between GetSecsTime and WallTime, and where monotonicSyncErrorSecs is error estimate between GetSecsTime and MonotonicTime.

(Dunno if monotonic time is a good name, but QueryPerformanceCounter is also monotonic at least [if implemented correctly])

I'm happy to help if you like. Guess i would need to implement a PsychGetWallClockSeconds() similar to PsychGetWallClockSeconds(), and then copy-paste the do-while loop and error check here Let me know if you'd like me to give it a stab.

On Mon, Aug 26, 2019 at 4:36 PM kleinerm notifications@github.com wrote:

Oh i was mistaken about my own code. The GetSecs('AllClocks') returns the same timestamp for both GetSecsTime and WallClock return args, because GetSecs == gettimeofday wall clock. I guess i'll need to extend GetSecs with another return argument 'otherClock' or something to deal with this :/ -- As i'm moving flats this week, i likely won't have much time or internet connectivity to do this now - In fact, today is the scheduled data of Internet shutdown at my old flat, so i expect to drop off the net any minute now.

On Mon, Aug 26, 2019 at 12:13 PM Diederick C. Niehorster < notifications@github.com> wrote:

Tobii said that they indeed use CLOCK_MONOTONIC.

Makes sense, it is the best choice for precision timestamping nowadays.

@kleinerm https://github.com/kleinerm if i understand you correctly, most

functions generating timestamps (by which i think of Screen Flips and PsychHID use APIs that use CLOCK_MONOTONIC) internally that you then map to gettimeofday() times? Perhaps a smooth transition would be to add a Screen Preference to use CLOCK_MONOTONIC instead. I'd be happy to help out.

Yes, display and audio timestamps, as well as HID input device timestamps and various other subsystem timestamps are nowadays in CLOCK_MONOTONIC by default, so PTB remaps internally to gettimeofday time, with a maximum allowed remapping error of 20 usecs if i remember correctly, but in practice the remapping is almost always/usually microsecond accurate so we don't pay a prize in accuracy, just in a tiny bit of overhead, but what is a sub-microsecond between friends?

-mario

But if you prefer, I can map as well (am I using GetSecs('AllClocks') correctly, and is it returning expected output?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNTOPKZZZOCY7LDIDGLQGOUF5A5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5D6GQQ#issuecomment-524804930 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAIXMNQAUMVNEYOBL6CFCRTQGOUF5ANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPKOSN73ZHF74IIGWTQGPS7BA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ER67Q#issuecomment-524885886, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGOQW5DMI3RJTMA7BGLQGPS7BANCNFSM4IKS6AEA .

[kleinerm]

Much to my surprise the internet is still working a day after the supposed shutdown. Lets see how long...

Anyway, the top of my GitHub master has rebuilt GetSecs for Linux, which returns a 4th argument CLOCK_MONOTONIC. -mario

On Tue, Aug 27, 2019 at 2:50 PM Diederick C. Niehorster < notifications@github.com> wrote:

Good luck with the move!

I guess an interface like this would possibly make sense: [GetSecsTime , WallTime, wallSyncErrorSecs, MonotonicTime, monotonicSyncErrorSecs] = GetSecs('AllClocks')

where wallSyncErrorSecs is error estimate between GetSecsTime and WallTime, and where monotonicSyncErrorSecs is error estimate between GetSecsTime and MonotonicTime.

(Dunno if monotonic time is a good name, but QueryPerformanceCounter is also monotonic at least [if implemented correctly])

I'm happy to help if you like. Guess i would need to implement a PsychGetWallClockSeconds() similar to PsychGetWallClockSeconds(), and then copy-paste the do-while loop and error check [here](

https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/2ad56475c2b5059701e2616cc1b77a6f6f20380b/PsychSourceGL/Source/Common/GetSecs/GetSecs.c ) Let me know if you'd like me to give it a stab.

On Mon, Aug 26, 2019 at 4:36 PM kleinerm notifications@github.com wrote:

Oh i was mistaken about my own code. The GetSecs('AllClocks') returns the same timestamp for both GetSecsTime and WallClock return args, because GetSecs == gettimeofday wall clock. I guess i'll need to extend GetSecs with another return argument 'otherClock' or something to deal with this :/ -- As i'm moving flats this week, i likely won't have much time or internet connectivity to do this now - In fact, today is the scheduled data of Internet shutdown at my old flat, so i expect to drop off the net any minute now.

On Mon, Aug 26, 2019 at 12:13 PM Diederick C. Niehorster < notifications@github.com> wrote:

Tobii said that they indeed use CLOCK_MONOTONIC.

Makes sense, it is the best choice for precision timestamping nowadays.

@kleinerm https://github.com/kleinerm if i understand you correctly, most

functions generating timestamps (by which i think of Screen Flips and PsychHID use APIs that use CLOCK_MONOTONIC) internally that you then map to gettimeofday() times? Perhaps a smooth transition would be to add a Screen Preference to use CLOCK_MONOTONIC instead. I'd be happy to help out.

Yes, display and audio timestamps, as well as HID input device timestamps and various other subsystem timestamps are nowadays in CLOCK_MONOTONIC by default, so PTB remaps internally to gettimeofday time, with a maximum allowed remapping error of 20 usecs if i remember correctly, but in practice the remapping is almost always/usually microsecond accurate so we don't pay a prize in accuracy, just in a tiny bit of overhead, but what is a sub-microsecond between friends?

-mario

But if you prefer, I can map as well (am I using GetSecs('AllClocks') correctly, and is it returning expected output?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <

https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNTOPKZZZOCY7LDIDGLQGOUF5A5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5D6GQQ#issuecomment-524804930

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AAIXMNQAUMVNEYOBL6CFCRTQGOUF5ANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPKOSN73ZHF74IIGWTQGPS7BA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ER67Q#issuecomment-524885886 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AANUOGOQW5DMI3RJTMA7BGLQGPS7BANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNUE2HZ3DEUGOWJC6RTQGUPHRA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5HTSXI#issuecomment-525285725, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXMNVDW6BKOLM5GG7KYZTQGUPHRANCNFSM4IKS6AEA .

[dcnieho]

The new GetSecs works great! Do you know if i can expect the offset between these two clocks to remain constant on a well-working system, or is it possible that they drift?

[dcnieho]

@iandol: current master should work on Linux now, if you use GetSecs mex file from Mario's master. Its lightly tested only, but seems fine to me. Curious to hear how it works for you!

[iandol]

OK, I don't have access to my spectrum pros ATM, but should do on Friday, so I'm happy to kick the tires, if everything seems to work, we can close it. Thanks @dcnieho and @kleinerm !!!

Regarding drift, wouldn't NTP cause one clock to shift relative to the other?

[kleinerm]

Yes. The GetSecs and monotonic clock are derived from the same hardware clock, but GetSecs receives periodic NTP time adjustments, wheras monotonic doesn't, so they will drift apart over time. The resync via GetSecs('AllClocks') is cheap though. You can set acceptable error bound as an optional parameter,default is 20 usecs, but yesterday i ran 10 million trial on a > 9 year old laptop while running youtube videos in parallel etc. and almost all samples have deviations / uncertainties of less than 0.5 usecs, with only very few outliers going into the single-digit usec range an maybe one or two getting to 19 usecs. So far all practical purposes the query/mapping is instant and accurate.

[dcnieho]

Thanks! So would recommended practice be to simply use the GetSecs('AllClocks') function to determine current offset between the two clocks, each time i have something to remap? That'd be fine :)

On Wed, Aug 28, 2019 at 7:19 PM kleinerm notifications@github.com wrote:

Yes. The GetSecs and monotonic clock are derived from the same hardware clock, but GetSecs receives periodic NTP time adjustments, wheras monotonic doesn't, so they will drift apart over time. The resync via GetSecs('AllClocks') is cheap though. You can set acceptable error bound as an optional parameter,default is 20 usecs, but yesterday i ran 10 million trial on a > 9 year old laptop while running youtube videos in parallel etc. and almost all samples have deviations / uncertainties of less than 0.5 usecs, with only very few outliers going into the single-digit usec range an maybe one or two getting to 19 usecs. So far all practical purposes the query/mapping is instant and accurate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGN4QS2F4WDVWTKWNT3QG2XTXA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5L26VY#issuecomment-525840215, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGKG6GOS6NHJFSD27RDQG2XTXANCNFSM4IKS6AEA .

[kleinerm]

Yes. Low overhead and reliable.

[iandol]

@dcnieho -- I just had a chance to try under linux (using Mario's updated GetSecs and your current HEAD), and get the following error:

Warning: The following error was caught while executing 'TobiiMex' class destructor:
Invalid MEX-file '/home/cog1/Code/Titta/TobiiMex/TobiiMex_matlab/64/TobiiMex_matlab.mexa64': libtobii_research.so:
cannot open shared object file: No such file or directory

Error in TobiiMex/cppmethodGlobal (line 62)
            [varargout{1:nargout}] = this.mexClassWrapperFnc(methodName, varargin{:});

Error in TobiiMex/stopLogging (line 135)
            this.cppmethodGlobal('stopLogging');

Error in TobiiMex/delete (line 98)
                this.stopLogging();

Error in TobiiMex (line 71)
            if nargin<1 || isempty(debugMode)

Error in Titta/init (line 188)
            obj.buffer = TobiiMex();

Error in tobiiManager/initialise (line 146)
            me.tobii.init();

Error in tobiiManager/runDemo (line 643)
                initialise(me,s); %initialise tobii with our screen 
> In TobiiMex (line 71)
  In Titta/init (line 188)
  In tobiiManager/initialise (line 146)
  In tobiiManager/runDemo (line 643) 

The folder with libtobii_research.so and TobiiMex_matlab.mexa64 is on the MATLAB path.

[dcnieho]

Ah yes, forgot about that. I ran into the same issue, and had to put the *.so files into /usr/lib i think it was.

I'd prefer to keep them where they are, but having them on matlab path is apparently not enough. @kleinerm, is it possible for me to keep the *.so files in the same directory and have loading the mex file succeed? I have googled extensively, but apparently not found the right combination of keywords

On Thu, 29 Aug 2019, 08:40 Ian Max Andolina notifications@github.com wrote:

@dcnieho https://github.com/dcnieho -- I just had a chance to try under linux (using Mario's updated GetSecs and yu current HEAD), and get the following error:

Warning: The following error was caught while executing 'TobiiMex' class destructor: Invalid MEX-file '/home/cog1/Code/Titta/TobiiMex/TobiiMex_matlab/64/TobiiMex_matlab.mexa64': libtobii_research.so: cannot open shared object file: No such file or directory

Error in TobiiMex/cppmethodGlobal (line 62) [varargout{1:nargout}] = this.mexClassWrapperFnc(methodName, varargin{:});

Error in TobiiMex/stopLogging (line 135) this.cppmethodGlobal('stopLogging');

Error in TobiiMex/delete (line 98) this.stopLogging();

Error in TobiiMex (line 71) if nargin<1 || isempty(debugMode)

Error in Titta/init (line 188) obj.buffer = TobiiMex();

Error in tobiiManager/initialise (line 146) me.tobii.init();

Error in tobiiManager/runDemo (line 643) initialise(me,s); %initialise tobii with our screen

In TobiiMex (line 71) In Titta/init (line 188) In tobiiManager/initialise (line 146) In tobiiManager/runDemo (line 643)

The folder with libtobii_research.so and TobiiMex_matlab.mexa64 is on the MATLAB path.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGKY432ZNJBQI3RONYDQG5VNVA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5NNQHA#issuecomment-526047260, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGKKKOWZ4VSIFWY7NJTQG5VNVANCNFSM4IKS6AEA .

[iandol]

OK, moving the libs manually and everything seems to be working 😃-- I can calibrate, validate, peek data to ensure gaze within trials and collect data. I don't yet have any real analysis routines worked out so can't quite test how reliable everything is[1]. I am going to add a photodiode to TTL-in on the Spectrum and test timing next week (too lazy to solder anything today!)...

Just to be clear, as an end user, should I run Titta.getTimeAsSystemTime() every trial or so to ensure clocks are kept in sync or is this done internally by Titta somewhere else?

---

[1] I assume you have some routines for analysis designed for the Titta data structure?

[dcnieho]

Hi Ian,

You will never have to call getTimeAsSystemTime yourself, all works fine if you just send along PTB timestamps to sendMessage. The remapping does not have internal state, and thus can't get out of sync. Where you might need the function is if you would like to peek or consume certain time ranges. Those functions operate on Tobii system time, not PTB time, and it would thus be good to have the relevant Tobii system timestamps acquired when needed. Note that sendMessage also returns the corresponding tobii system timestamp

I have some routines laying around optimized for fixation detection. I plan to provide a demo script for that. Would that be of interest to you?

On Fri, Aug 30, 2019 at 1:07 PM Ian Max Andolina notifications@github.com wrote:

OK, moving the libs manually and everything seems to be working 😃-- I can calibrate, validate, peek data to ensure gaze within trials and collect data. I don't yet have any real analysis routines worked out so can't quite test how reliable everything is[1]. I am going to add a photodiode to TTL-in on the Spectrum and test timing next week (too lazy to solder anything today!)...

Just to be clear, as an end user, should I run Titta.getTimeAsSystemTime() every trial or so to ensure clocks are kept in sync or is this done internally by Titta somewhere else?

[1] I assume you have some routines for analysis designed for the Titta data structure?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGIRWJWUQES5NS3EUXDQHD5NLA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5RK64Y#issuecomment-526561139, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGIJKRAPI5N7NJ3GMSDQHD5NLANCNFSM4IKS6AEA .

[iandol]

Ok good to know.

No rush on the analysis code, I do have an analysis class for eyelink, but haven't have time to adapt it yet, so if you have anything off-the-shelf working with Titta and are happy to share that would be great, but please don't waste any time on it. I'll just do coarse plotting in the interim, it will be enough to get where I need.

Do you ever use timing confirmation with a photodiode input into the spectrum?

[dcnieho]

No worries, i am planning to provide that anyway. Hopefully i get to it next week.

You mean latency of physical event to that being available in the eye tracker data stream? No i haven't. Would be curious to hear what you find

On Sat, Aug 31, 2019 at 5:03 AM Ian Max Andolina notifications@github.com wrote:

Ok good to know.

No rush on the analysis code, I do have an analysis class for eyelink, but haven't have time to adapt it yet, so if you have anything off-the-shelf working with Titta and are happy to share that would be great, but please don't waste any time on it. I'll just do coarse plotting in the interim, it will be enough to get where I need.

Do you ever use timing confirmation with a photodiode input into the spectrum?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPXNHFZPYBGKGULT3DQHHNQPA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TD4GQ#issuecomment-526794266, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGNQCVMJVHVZQNIYPNDQHHNQPANCNFSM4IKS6AEA .

[kleinerm]

Wrt. .so library placement, the below section of the below man-page would be relevant:

http://man7.org/linux/man-pages/man8/ld.so.8.html

"Rpath token expansion The dynamic linker understands certain token strings in an rpath specification (DT_RPATH or DT_RUNPATH). Those strings are substituted as follows:

   $ORIGIN (or equivalently ${ORIGIN})
          This expands to the directory containing the program or shared
          object.  Thus, an application located in somedir/app could be
          compiled with

              gcc -Wl,-rpath,'$ORIGIN/../lib'

          so that it finds an associated shared object in somedir/lib no
          matter where somedir is located in the directory hierarchy.
          This facilitates the creation of "turn-key" applications that
          do not need to be installed into special directories, but can
          instead be unpacked into any directory and still find their
          own shared objects.

"

Iow. building the mex files with some option like "-Wl,-rpath,'$ORIGIN'" on Octave might do the trick. Or maybe something like LDFLAGS='$LDFLAGS -Wl,-rpath,'$ORIGIN'' to properly pass on Octave and Matlab. Usual fiddling with ' ' vs. "" and escapes and stuff applies.

-mario

On Sat, Aug 31, 2019 at 9:33 AM Diederick C. Niehorster notifications@github.com wrote:

No worries, i am planning to provide that anyway. Hopefully i get to it next week.

You mean latency of physical event to that being available in the eye tracker data stream? No i haven't. Would be curious to hear what you find

On Sat, Aug 31, 2019 at 5:03 AM Ian Max Andolina notifications@github.com wrote:

Ok good to know.

No rush on the analysis code, I do have an analysis class for eyelink, but haven't have time to adapt it yet, so if you have anything off-the-shelf working with Titta and are happy to share that would be great, but please don't waste any time on it. I'll just do coarse plotting in the interim, it will be enough to get where I need.

Do you ever use timing confirmation with a photodiode input into the spectrum?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGPXNHFZPYBGKGULT3DQHHNQPA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TD4GQ#issuecomment-526794266, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGNQCVMJVHVZQNIYPNDQHHNQPANCNFSM4IKS6AEA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dcnieho]

Thanks Mario! That was just the info i needed. Adding -Wl,-rpath,'$ORIGIN' to LDFLAGS did the trick.

@iandol, you should be able to remove the libtobii_research* files from /usr/lib and things should work with current master.

[kleinerm]

Btw. i think it would make sense to reference/link to your work somewhere on the PTB Wiki, so people with those eyetrackers find it easily, once you are comfortable with the quality.

[dcnieho]

Thanks, good point! I have added links in the hardware/specific hardware section. The toolbox should be production ready now :)

On Fri, Sep 6, 2019 at 4:05 PM kleinerm notifications@github.com wrote:

Btw. i think it would make sense to reference/link to your work somewhere on the PTB Wiki, so people with those eyetrackers find it easily, once you are comfortable with the quality.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGMWQRTEETVPAPQGJ2DQIJPRDA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6C6HUQ#issuecomment-528868306, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGL4FR57Y7RNVZ56363QIJPRDANCNFSM4IKS6AEA .

[kleinerm]

Don't be shy about advertising it on the forum as well.

On Fri, Sep 6, 2019 at 10:07 PM Diederick C. Niehorster < notifications@github.com> wrote:

Thanks, good point! I have added links in the hardware/specific hardware section. The toolbox should be production ready now :)

On Fri, Sep 6, 2019 at 4:05 PM kleinerm notifications@github.com wrote:

Btw. i think it would make sense to reference/link to your work somewhere on the PTB Wiki, so people with those eyetrackers find it easily, once you are comfortable with the quality.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub < https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGMWQRTEETVPAPQGJ2DQIJPRDA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6C6HUQ#issuecomment-528868306 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AANUOGL4FR57Y7RNVZ56363QIJPRDANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNXO5MKAWLRNLEEUQUTQIKZ6RA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6D5QOA#issuecomment-528996408, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXMNSNQT3BTI7TNNHHNATQIKZ6RANCNFSM4IKS6AEA .

[dcnieho]

Thanks for that idea as well! Somehow i haven't thought of it myself.

On Fri, Sep 6, 2019 at 10:12 PM kleinerm notifications@github.com wrote:

Don't be shy about advertising it on the forum as well.

On Fri, Sep 6, 2019 at 10:07 PM Diederick C. Niehorster < notifications@github.com> wrote:

Thanks, good point! I have added links in the hardware/specific hardware section. The toolbox should be production ready now :)

On Fri, Sep 6, 2019 at 4:05 PM kleinerm notifications@github.com wrote:

Btw. i think it would make sense to reference/link to your work somewhere on the PTB Wiki, so people with those eyetrackers find it easily, once you are comfortable with the quality.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <

https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGMWQRTEETVPAPQGJ2DQIJPRDA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6C6HUQ#issuecomment-528868306

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AANUOGL4FR57Y7RNVZ56363QIJPRDANCNFSM4IKS6AEA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AAIXMNXO5MKAWLRNLEEUQUTQIKZ6RA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6D5QOA#issuecomment-528996408 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAIXMNSNQT3BTI7TNNHHNATQIKZ6RANCNFSM4IKS6AEA

.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGI7YQKVTTNICSZSNTLQIK2SBA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6D54KA#issuecomment-528997928, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGM6EE3TVCVN43DEJUDQIK2SBANCNFSM4IKS6AEA .

[iandol]

You mean latency of physical event to that being available in the eye tracker data stream? No i haven't. Would be curious to hear what you find

Yes, I'm testing with a photodiode box I made and I've got a consistent 9ms timing difference, but as my oscilloscope broke I'm waiting for a new one to exclude any hardware signal issues. I would expect a ~2ms max difference right, considering the roundtrip timing of using the SDK and whether VBL is close to stimulus-on time (which depends on hardware)?

[dcnieho]

Ah, if i understand correctly you are measuring physical event until corresponding screen update? The manual claims a total system latency of "Less than 3 frames (eg. <2.5 ms at 1200 Hz)". What fs are you running at? How are you creating the physical event?

On Mon, Sep 9, 2019 at 6:00 AM Ian Max Andolina notifications@github.com wrote:

You mean latency of physical event to that being available in the eye tracker data stream? No i haven't. Would be curious to hear what you find

Yes, I'm testing with a photodiode box I made and I've got a consistent 9ms timing difference, but as my oscilloscope broke I'm waiting for a new one to exclude any hardware signal issues. I would expect a ~2ms max difference right, considering the roundtrip timing of using the SDK and whether VBL is close to stimulus-on time (which depends on hardware)?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGM3XNELWJCNOSTIBATQIXC5FA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6GFMQQ#issuecomment-529290818, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGPGHQPSY2RDP6VBIJDQIXC5FANCNFSM4IKS6AEA .

[iandol]

Sorry Dee, my current testing is much more simple: Flip the screen to white, and measure the light with a TSL-252R photodiode (7µs rise time), when it reaches a threshold convert to a TTL sent to the Spectrum (recorded as an external event with a system timestamp, Spectrum has a 50µs sampling interval). After the flip is finished I immediately sendMessage() and that also has a system timestamp. Comparing the timestamps and there is a consistent 9ms delay. I'm currently worried that it is my LabJack (that converts my thresholded voltage to a TTL) that is to blame so I'm waiting for my new oscilloscope to test. I'll update here when I get confirmation, but this is just a first-order "sanity" check to the sync between PTB and Tobii.

I also think "physical event" (pupil constriction, saccade etc.) timing is important, but I will have to trust Tobii as building artificial eyes to create known events is way out of my remit ;-)

[dcnieho]

Ah, I see. (Yeah, doing physical event timing like that is hard with the spectrum..)

Aren't you measuring pixel response time + panel's internal processing delay as well like this, i.e., wouldn't that explain some part of the delay? Or are you using a CRT that shouldn't have this? Note that i am interpreting delay as in TTL in comes reliably 9 ms later than flip completion timestamp.

I don't think there is a roundtrip to Tobii SDK involved in timing. I believe (don't know), that what Tobii does is periodically sync device time to system time, and then simply remap times that come in

On Tue, Sep 10, 2019 at 4:56 AM Ian Max Andolina notifications@github.com wrote:

Sorry Dee, my current testing is much more simple: Flip the screen to white, and measure the light with a TSL-252R photodiode (7µs rise time), when it reaches a threshold convert to a TTL sent to the Spectrum (recorded as an external event with a system timestamp, Spectrum has a 50µs sampling interval). After the flip is finished I immediately sendMessage() and that also has a system timestamp. Comparing the timestamps and there is a consistent 9ms delay. I'm currently worried that it is my LabJack (that converts my thresholded voltage to a TTL) that is to blame so I'm waiting for my new oscilloscope to test. I'll update here when I get confirmation, but this is just a first-order "sanity" check to the sync between PTB and Tobii.

I also think "physical event" (pupil constriction, saccade etc.) timing is important, but I will have to trust Tobii as building artificial eyes to create known events is way out of my remit ;-)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/dcnieho/Titta/issues/1?email_source=notifications&email_token=AANUOGJWIM52NDTSR2YBFM3QI4EEXA5CNFSM4IKS6AEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JUZ2A#issuecomment-529747176, or mute the thread https://github.com/notifications/unsubscribe-auth/AANUOGKECCGOGWHUC4UKTX3QI4EEXANCNFSM4IKS6AEA .