1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

TUIO 2.0 specification changes proposal

This forum is reserved to the discussion of the present and future of the TUIO protocol specification. See http://www.tuio.org/

Moderator: modin

TUIO 2.0 specification changes proposal

Postby xrusnak » Thu Jul 14, 2011 2:58 pm

I'm from the research group interested in distributed collaborative environments and new methods of interactions on tiled displays. Our special interest is in multi-touch technologies for tiled-screens.

Currently, we have built a small multi-touch tabletop from commodity HW and touch panels we have had. Currently we finalized HW part of the quad-touch table (4x Mac Mini with Ubuntu Linux on them, 4x 22" LCD panel 1680x1050, 4x CycloTouch R Series, interconnected via 1Gb network) -- sample picture is at http://www.sitola.cz/wordpress/wp-conte ... g_3975.jpg. The visualization part is based on SAGE middleware (http://www.sagecommons.org/) We are also interested in possibilities of interaction devices.
Now, we are going to start developing some applications for it with a special focus on gesture recognition in such kind of distributed environment. We already started implementation of C++ API according to a TUIO 2.0 Specification, but we come across several difficulties in current specification which makes it badly usable for our purposes. We would like to discuss them to find some possibilities in changing TUIO 2.0 Specification.

Mainly we need to transform current form of frame message (FRM) which is defined as: /tuio2/frm f_id time [app addr inst dim]

Our main problem is, that we need to have each sensor explicitly specified as a single object. We are aware of the main ideas of TUIO - be as flexible as possible for basicaly any kind of sensor while keeping the advantages of a high-level protocol. We are aware that our that our proposal is partialy going against it, but since the interactive large display walls become more and more often in academia and public places (such as museums), it could worth. We also think, the proposed changes would make the work with the sensors arrays more straightforward.

Thus we would like to suggest following changes:

Splitting FRM into two separate messages and partially reorder attributes:

1. frame message (FRM)
Code: Select all
/tuio2/frm f_id time [app inst addr_sel {IPv4|MAC|IPv6 addr}]

- f_id, time, app and inst have the same meaning as in the original specification
- the inst field is placed before the more complex address part of the message (simplification of message parsing)
- adding the new addr_sel (address selector) which differentiates in between IPv4, IPv6 and MAC addresses
- we have one more suggestion for address attribute -- replace string type four 32bit unsigned integers (to cover whole IPv6 address), extension of various types of IP addresses (especially the IPv6 ones) might be useful in the future

- another possible way of handling addresses is to have different size of the addr part of the message: one 32bit uint for IPv4, two 32bit uint for MAC and four 32bit uint for IPv6. In this case, the addr_sel is not necessary.

2. sensor message (SNR)
Code: Select all
/tuio2/snr dim xres yres xpos ypos

- dim attribute encodes the sensor dimension in pixels with two 16bit unsigned integer values embedded into a 32bit integer value.
- xres and yres are resolutions of the sensor in dots per inch (or alternatively dimension in millimeters, this is a thing we still discuss)
- xpos and ypos defines X and Y coordinates in a matrix of sensors, this one is actually the most important pair of attributes for us.

We would be really grateful for any comments, suggestions as well as discussion concerning the proposal and the general topic of using TUIO 2.0 for large tiled-screens with multi-touch support. Thank you in advance.
Posts: 2
Joined: Thu Jun 02, 2011 11:07 am

Return to TUIO Specification Forum

Who is online

Users browsing this forum: No registered users and 1 guest