On Mon, 2008-09-08 at 16:28 +0000, Martin Peach wrote:
Roman Haefeli wrote:
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.
Yes, I'm working on it. I tried a few approaches yesterday that didn't work. I think if the input to [unpackOSC] only contains complete packets it's possible. A version that takes one byte at a time calls for a serious rewrite.
yo.. you probably know more about tcp than i do. is it a robust approach to assume, that tcp always delivers at least complete or multiples of complete packets?
if there'd be an easy way to tell when an OSC packet starts and when it ends, i would do the packet forming on the receiver side myself (in pd). but it seems, that one needs to parse a lot of the info of the OSC packet and it seems that it is not so straightforward to do.
actually, because of the same 'you cannot tell how tcp forms packets' problem, another netpd-server based on [tcpserver] i wrote doesn't work correctly. because it transports FUDI messages, i can make a [FUDI_packet_former] by waiting for a 59 10 sequence (;\n) in the stream to solve the problem. however, this shows, that this problem is not only related to OSC, but is a general problem of [tcp*]: you have to serialize lists anyway, so i wonder whether it would be harmful, if [tcp*] would do it already.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de