You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@cboulay I am currently trying to extend the plugin to support surface mapped gaze. But the one channel_format-per-outlet rule is making life difficult for me.
While in a perfect world, every surface would have its own outlet, this is not feasible for the LSL Relay plugin without intertwining it deeply with Capture's Surface Tracker plugin. I thought of building a flexible outlet following the tidy data approach:
LSL timestamp
surface name
norm_pos_x
norm_pos_y
confidence
is on surface
t
Screen left
0.5
0.5
1.0
True
t
Screen right
-1.5
0.5
1.0
False
t+1
Screen left
1.5
0.5
1.0
False
t+1
Screen right
0.5
0.5
1.0
True
As mentioned above, I am not able to mix the string column with the double columns (I think). If I understood the documentation correctly, one should be building time-synced outlets instead. @cboulay Would the following outlet layouts conform to LSL best practices? If not what would you recommend? I am only semi-happy with the solution below.
Surface Name outlet (type: string)
LSL Timestamp
Surface ID
Surface Name
t
1.0
Surface left
t
2.0
Surface right
t+1
1.0
Surface left
t+1
2.0
Surface right
Surface ID would correspond to the string representation of the surface id. Surface ids would be incrementing integers in the order of appearance in the processed data.
Surface Gaze outlet (type: double)
LSL timestamp
surface id
norm_pos_x
norm_pos_y
confidence
is on surface
t
1.0
0.5
0.5
1.0
1.0
t
2.0
-1.5
0.5
1.0
0.0
t+1
1.0
1.5
0.5
1.0
0.0
t+1
2.0
0.5
0.5
1.0
1.0
The text was updated successfully, but these errors were encountered:
One alternative would be to use the original single-outlet design with a string format and using either the string representation for the floats or struct.pack. Both do not seem particularly satisfying to me.
We are using App-PupilLabs in our research and even your second solution will be great for our goal (because we only have one surface which is a screen).
Could you please help with sharing codes or any implementation hints?
@cboulay I am currently trying to extend the plugin to support surface mapped gaze. But the one
channel_format
-per-outlet rule is making life difficult for me.While in a perfect world, every surface would have its own outlet, this is not feasible for the LSL Relay plugin without intertwining it deeply with Capture's Surface Tracker plugin. I thought of building a flexible outlet following the tidy data approach:
As mentioned above, I am not able to mix the string column with the double columns (I think). If I understood the documentation correctly, one should be building time-synced outlets instead. @cboulay Would the following outlet layouts conform to LSL best practices? If not what would you recommend? I am only semi-happy with the solution below.
Surface ID
would correspond to the string representation of the surface id. Surface ids would be incrementing integers in the order of appearance in the processed data.The text was updated successfully, but these errors were encountered: