Hi,
I've been using mrpeach
[packOSC]
|
[udpsend]

what is the equivalent of this using [netsend]?

@youaresound The space seems to come from the slash in [oscformat /]. I have never used osc, so i don't know what this all means, but maybe just use something else as osc adress like [oscformat something] and get rid of the something address after receiving using [route something] for example?

On a side note, your [pd numbers] is doing nothing, i.e. input equals output...

you are right about the slashes. i replaced it with the first part of the message address tuio.

edit: you are right about the numbers too. don't know what i was doing wrong that was breaking the connection thanks

what i am trying to figure out is why the messages from oscformat and packOSC still don't match but print the same message and only the packOSC version works sending the tuio message.

are they formatting the floats differently?

this is the same message:

packOSC:
47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 102 115 101 113 0 0 0 0 0 0 0 3
oscformat:
47 116 117 105 111 0 0 0 44 115 115 102 0 0 0 0 50 68 99 117 114 0 0 0 102 115 101 113 0 0 0 0 64 64 0 0

oscparse both:

print: list tuio 2Dcur fseq 3
print: list tuio 2Dcur fseq 3

@youaresound i suspect part of the reason is that you are sending different messages, so they are encoded differently. encoding is just exchanging the characters with their ASCII equivalent, see here: https://en.wikipedia.org/wiki/ASCII#Printable_characters

i wonder what happens if you use /tuio/2Dcur as osc address.

@youaresound This should help.
I have checked that messages are received correctly in extended as well, and I have checked that the packets are exactly the same as those sent by [packOSC].
cleaner.pd
David.

thank you both for looking at this... i now have a bit better understanding. i am still not sure why the messages are being encoded differently.

i am including an edit of the cleaner patch. that prints the same message coming from each object. here is each message side by side.

the first one is exactly the same but the others aren't.

parse: list tuio 2Dcur source localhost
pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 115 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0
form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 115 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0

parse: list tuio 2Dcur alive 9
pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 97 108 105 118 101 0 0 0 0 0 0 9
form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 0 97 108 105 118 101 0 0 0 65 16 0 0

parse: list tuio 2Dcur set 1 2 3 4 5 6
pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 105 105 105 105 105 0 0 0 0 115 101 116 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6
form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 102 102 102 102 102 0 0 0 0 115 101 116 0 63 128 0 0 64 0 0 0 64 64 0 0 64 128 0 0 64 160 0 0 64 192 0 0

parse: list tuio 2Dcur fseq 15
pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 102 115 101 113 0 0 0 0 0 0 0 15
form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 0 102 115 101 113 0 0 0 0 65 112 0 0

cleaner-edit.pd

@youaresound This seems to happen because no format is given. If you give the "format si" for the message "alive 9" you get the same result as with packOSC. "format si" means the message contains one string (s) and one integer (i).

With added format, both ways give the exact same results: cleaner-edit2.pd

I enjoyed that film...... and @ingox beat me to it......

@youaresound [packOSC] is setting the values as integers, and [oscformat] is setting them as floats...105 = i... 102 = f
Are the messages getting through to Tuio using [cleaner].......? It would be good to know if it cares whether it receives a specific type.

I have to say that I still prefer "Extended" for more reasons than I can remember.
But I will remember this one.......
Here you go....... solved........cleaner2.pd
David.

@whale-av haha, what film? didn't get the reference...

just curious is it necessary to specify a float with format if a message were to contain both floats and integers.

The messages now look exactly the same but it is still not sending the tuio messages in the way it expects.

the (tuio 2Dcur set) message i am sending is actually
float float int int int float. or possibly all floats.

i really appreciate the feedback, i had no idea how to even go about it as the help file was not clear to me.

even using packOSC which works the connection can break easily. the tuio client itself is very picky. when a float becomes an integer it can break the connection.

@ingox..... I was watching a good film on TV..... you would not have beaten me to posting the solution otherwise....

@youaresound The Tuio spec is horrible...... https://www.tuio.org/?specification
It seems that it expects a bundle of messages in the correct order, that fill a UDP packet.
What is more...... some messages expect a mixture of floats and integers.
So a 2D set message expects......
int32, float32(range 0-1), float32(range 0-1), float32, float32, float32
It might not be all that interested though............ as a "bundle" has to be sent..

  /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

and for each bundle that changes parameters (not redundant) the fseq frame_id must be incremented. Reading, and nearly understanding some of it, I guess it should look like.....

  /tuio/2Dcur source Pd
  /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

I searched my old backups...... and found this....... tuio_works.pd which seems to claim (in its name) that it was working. The send/receive names suggest that it is yours, or something we worked on previously......
David.

man thank you david. it works now. thanks for reviewing the documentation.

just had to specify int float. in the message.