On Mon, 2008-09-08 at 09:08 -0400, Martin Peach wrote:
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.
yeah, i agree. but what is with messages, that follow each other with less than 8ms and more than 0ms? there is no solution for that. from a user perspective, you don't always know beforehand in what time intervals OSC packets are going to be sent. to cover any case, the only proper solution i can think of is, that [unpackOSC] works stream based and not message based.
may i ask, if there are plans to change [unpackOSC]? the reason i ask is, that i am currently stuck with the development of netpd because of this. if it stays as it is, i'll bury my plans to switch netpd to OSC.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de