Roman Haefeli wrote: > please correct me, if interprete things the wrong way, but from my tests > [tcp*] and [unpackOSC] don't work 'well' together. [tcp*] seem to not > know anything about messages, they simply treat any incoming data as a > stream (without any concept of delimiters). depending on how quickly you > send messages to the sending object, the receiving object makes one or > more pd messages out of it (this most likely happens on the tcp layer, > where pd/[tcp*] assumingly doesn't have any influence on). [unpackOSC] > on the other hand is 'stream agnostic', it only accepts input as > messages with correct number of elements. messages that are longer than > one OSC packet are truncated to exactly one OSC packet, while the rest > is silently ignored. if one message to [unpackOSC] is too short, > [unpackOSC] drops an error: > > unpackOSC: packet size (19) not a multiple of 4 bytes: dropping packet > > from what i can tell, [tcp*] and [unpackOSC] are incompatible, since the > former are 'message agnostic' and the latter is 'stream agnostic'. > > if i am right about this, i really hope, that it could be fixed in some > way. my suggestion would be to change [unpackOSC] in way, so that it > treats incoming messages as a [stream] (in other words: it would > completely disregard messages and always give an output, as soon as an > OSC packet is completed). > > this is no problem as long as you use [unpackOSC] together with [udp*], > since then you would expect some messages to drop. but when going the > tcp route, you'd expect completeness on the receiving side. currently it > is not possible to rely on this, as this little test shows: > > [send /test 1, send /best 2( > | > [packOSC] > | > [tcpclient] > > [tcpserver] > | > [unpackOSC] > | > [print] > > it prints: > > /test 1 > >
Actually the proper way to deal with sending multiple OSC messages at the same time is to put them into a bundle. Then [unpackOSC] will unpack them and output them in sequence. Martin _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
