@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 |
@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 IDwould correspond to the string representation of the surface id. Surface ids would be incrementing integers in the order of appearance in the processed data.