Problems sending TUIO

Hi
I am trying to send TUIO curser messages… but it is not working.

I don’t get fseq and alive messages.

But instead i get 2DOBJ and 2DBLB messages.
any idea?

Thx, greetings and stay healthy

Christian

I have also tried the TUIO Bundler help patch: same proble. If i move the curser, i don’t get the alive or fseq messages.

Greetings

Christian

True, what the TUIOBundler helppatch does not explain is that you have to disable sending of obj and blb messages if you’re not interested in them. do so by setting the “Object Bin Size” and “Blobs Bin Size” inputs from -1 to 0.

then you should only receive the cursor messages. i just tested with beta40 and the TUIOBundler helppatch and it does send out cursor fseq and alive messages correctly for me.

the simplest test to see it working is connecting a TUIOCursor (Network Split) right to the output of the TUIOBundler. if you now send a cursor into the bundler, you’ll see the split node return the same values. that would confirm that TUIO encoding and decoding works.

Hi Joreg

Thx for answering on a saturday evening!

OK… Setting the Blob size to 0 is working!

But is it possible, that you don’t follow the TUIO specs?

What i have in mind ist, that the bundle should be in this order:
alive, set, fseq

But if i check the output of the bundle i get
set, alive, fseq

What i try to do is at the end: combine 3 touch frames, remap the TUIO data and send it as one new TUIO to an application what is sadly not vvvv ;(
Maybe they just accepting TUIO messages which are in the right order?

Greetings

Christian

It ssems, that the Bundle what vvvv is sending is not correct.

in the attached screenshot you can see on the left site what a tuio simulator is sending and on the right site what vvvv is sending. Beside the fact, that it is sending in the wrong order, it is also wrong in configuration. the fsec normaly is sending a string and an int. And the alive a string and as many ints as we have touch id’s. This seems be be wrong if i take a look in the raw message.

Greetings

Christian

OK
right order is something i can fix in the vl patch… but correcting the type tag is something what is above my mind ;)

The problem seems to be here in this vl patch:

What i think is, that you set the typetags for alive and fseq out of every letter of the string alive and fseq, but not from the real arguments.

Greetings

Christian

confirmed. thanks for digging into this.
indeed instead of a string, weirdly multiple chars are sent here.
regarding the order. interesting, i would not have thought that this should matter, but if it does, i’ll adapt it.
working on a new build. will let you know when a new beta-preview with a fix is available.

please try latest beta41-preview now.

Dear Joreg

Thanks for the good support… and we are almost there. At least on the final lap ;)

TUIO Set is now working as expected!!!

But: It seems that you not remove the points.
After removing the last Touch Point the you don’t send an empty alive.

I hope, i am doing something wrong… but don’t know what.

This is the spec from TUIO:

Message & Bundle Format

Since TUIO is implemented using Open Sound Control (OSC) [4] it follows its general syntax. A TUIO client implementation therefore has to make use of an appropriate OSC library such as oscpack or liblo, and has to listen to the following message types and bundle structure, which in this example are referring to the two-dimensional Cursor profile.

/tuio/2Dcur source application@address /tuio/2Dcur alive s_id0 … s_idN /tuio/2Dcur set s_id x_pos y_pos x_vel y_vel m_accel /tuio/2Dcur fseq f_id

A typical TUIO bundle will contain an initial ALIVE message, followed by an arbitrary number of SET messages that can fit into the actual bundle capacity and a concluding FSEQ message. A minimal TUIO bundle needs to contain at least the compulsory ALIVE and FSEQ messages. The FSEQ frame ID is incremented for each delivered bundle, while redundant bundles can be marked using the frame sequence ID -1.
The optional source message can be transmitted to allow the multiplexing of several TUIO trackers on the client side. The application@address argument is a single string that specifies the application name and any unique source address (IP, host name, MAC address). If sent on localhost, the second address part can be omitted, hence any string without the @ separator implicitly comes from localhost.

That means, that after removing all touch points we should get a bundle:

  • alive without arguments
  • fseq with the sequence ID

This is how the TUIO Simulator from Mr. Kaltenbrunner is sending the TUIO messages.

To make sure, that we will delete the touch points even if the last bundle without the arguments is not received, you could send this bundle in a cycled loop.

This is not urgent! But of course it would be great, if this issue could be fixed.

Many thanks

Christian

This is a screenshot, how i receive a TUIO message from the TUIO-Simulator. The last two rows showing the empty alive and missing set message.

image

1 Like

another good find, thanks for that! again please try the latest beta41-preview which should now have this fixed.

YESS!!!

Perfect, Thx a lot!

And: unbelievable support!!

Greetings

Christian

And it works!

Merging and remapping two different TOUCH-frames and sending it as one TUIO stream ;)

image

THX again!!

Glad to see it work and thanks again for the digging!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.