otudp vs. udpsend/receive - OSC problem
Hi,
I have been using a P5 gaming glove with Max/MSP on a G4 mac - on a PPC the patch relies on an external called otudp. I am now trying to install the glove on a new Intel machine, and believe that the otudp object has been replaced by udpsend and udpreceive externals.
Does anyone know how I would go about adapting the old patch to work with udpsend/receive? Any help would be greatly appreciated, since I need to use the glove for a performance in a few days!!
Thanks,
David Litke
litke_david@hotmail.com
It should be pretty straight forward, check the help files for udpsend/
udpreceive, and the subpatcher about cnmat compatibility.
/J
04/07/07, kl. 7:55 +0200 , skrev David Litke:
>
>Hi,
>I have been using a P5 gaming glove with Max/MSP on a G4 mac - on a PPC
>the patch relies on an external called otudp. I am now trying to
>install the glove on a new Intel machine, and believe that the otudp
>object has been replaced by udpsend and udpreceive externals.
>
>Does anyone know how I would go about adapting the old patch to work
>with udpsend/receive? Any help would be greatly appreciated, since I
>need to use the glove for a performance in a few days!!
>
>Thanks,
>David Litke
>litke_david@hotmail.com
thanks for your reply - what I'm still not sure about is how the arguments supplied to otupd translate to the udpreceive. The patch has a otudp object with "read 47110 nbufs 5 bufsize 256" supplied as arguments. I couldn't find a help file about otudp, and it doesn't look like udpreceive takes any more arguments besides host and port number. Do you think that I can just replace the otudp with a udpreceive (the outlet of otudp goes into a OpenSoundControl object, so I'm assuming I would use the udpreceive object)?
Thanks very much for your help - I really appreciate it since I'm presenting at SMC next week!
Sincerely,
David Litke
05/07/07, kl. 18:59 +0200 , skrev David Litke:
>thanks for your reply - what I'm still not sure about is how the
>arguments supplied to otupd translate to the udpreceive. The patch has
>a otudp object with "read 47110 nbufs 5 bufsize 256" supplied as
>arguments. I couldn't find a help file about otudp, and it doesn't look
>like udpreceive takes any more arguments besides host and port number.
>Do you think that I can just replace the otudp with a udpreceive (the
>outlet of otudp goes into a OpenSoundControl object, so I'm assuming I
>would use the udpreceive object)?
OK. I wouldn't worry to much about nbufs and bufsize and just try
"udpreceive 47110 CNMAT"
/J
Quote: litke_david@hotmail.com wrote on Thu, 05 July 2007 09:59
----------------------------------------------------
> thanks for your reply - what I'm still not sure about is how the arguments supplied to otupd translate to the udpreceive. The patch has a otudp object with "read 47110 nbufs 5 bufsize 256" supplied as arguments. I couldn't find a help file about otudp, and it doesn't look like udpreceive takes any more arguments besides host and port number. Do you think that I can just replace the otudp with a udpreceive (the outlet of otudp goes into a OpenSoundControl object, so I'm assuming I would use the udpreceive object)?
>
> Thanks very much for your help - I really appreciate it since I'm presenting at SMC next week!
>
> Sincerely,
> David Litke
----------------------------------------------------
FYI: otudp was a CNMAT object that has been made obsolete by udpsend/udpreceive; I've attached the help file if you're interested.
You could ignore this following paragraph:
The default buffers for udpreceive are bigger that the buffers being set by "nbufs 5 bufsize 256" (which are even smaller than the default for otupd). If you are worried about wasting memory, could could use the "maxqueuesize" and "maxpacketsize" messages to udpreceive to perform the similar function. I think this is basically academic, and you'll never notice the difference