Forums > MaxMSP

otudp vs. udpsend/receive – OSC problem

July 5, 2007 | 5:55 am

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


July 5, 2007 | 9:11 am

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


July 5, 2007 | 4:59 pm

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


July 5, 2007 | 5:32 pm

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


July 5, 2007 | 7:10 pm

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

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N vpatcher 42 354 462 561;
#P window setfont "Sans Serif" 14.;
#P comment 4 133 346 196622 http://www.yowstar.com/share/OTUDPprimer.zip;
#P window setfont "Sans Serif" 9.;
#P comment 3 24 254 196617 We recommend downloading Peter Nyboer’s OTUDP primer (zip or sit) for an example of Max to Max communication with these objects and information on how to configure networking settings on Mac OSX , Mac OS9 , and Windows.;
#P window setfont "Sans Serif" 14.;
#P comment 4 96 346 196622 http://www.yowstar.com/share/OTUDPprimer.sit;
#P window setfont "Sans Serif" 9.;
#P comment 7 118 100 196617 or;
#P pop;
#P newobj 293 370 101 196617 p The OTUDP Primer;
#P message 543 260 109 196617 host 127.0.0.1 12345;
#P comment 639 298 115 196617 Not very useful to you.;
#P message 543 311 81 196617 resetdebugstats;
#P message 543 294 55 196617 debugstats;
#P window linecount 2;
#P comment 132 151 150 196617 Highly verbose dump of object’s state to the Max window.;
#P window linecount 1;
#P message 44 157 85 196617 tellmeeverything;
#P comment 660 375 167 196617 23 March 2005;
#P comment 661 362 167 196617 Matt Wright & Michael Zbyszynski;
#P comment 18 119 211 196617 Some stuff you can send to otudp read:;
#P message 34 137 95 196617 receiveport 12345;
#P comment 132 136 120 196617 Change the port-number.;
#P window linecount 10;
#P comment 14 325 257 196617 Incoming packets are stored temporarily in buffers allocated by this object. (Also , �if you’re in overdrive , each outgoing packet is temporarily copied into one of these buffers.) You set the size of these buffers (which determines the maximum sized UDP packet that can be sent in overdrive or received at all) and the number of these buffers. (More buffers require more memory , but if you don’t have enough , incoming packets will be dropped if they come too fast for your patch to process them.)�;
#P window linecount 1;
#P message 543 241 115 196617 host foo.bar.com 12345;
#N vpatcher 430 200 769 561;
#P window setfont "Sans Serif" 9.;
#P comment 31 289 266 196617 Likewise , there’s no good way to produce a buffer of data to put in a UDP packet from within Max other than writing an external.;
#P comment 31 238 266 196617 There’s not much you can do in Max with an int that happens to be a pointer to some binary data , except pass it to an external (like CNMAT’s "OpenSoundControl") that reads the binary data and outputs Max-style data.;
#P comment 31 162 266 196617 �Incoming packets outputted by "otudp read" and outgoing packet sent to "otudp write" are represented the same way in Max. The message "FullPacket" has two arguments: the number of bytes in the packet , and a pointer to the memory holding the data in the packet , represented as a Max int.;
#P comment 31 123 266 196617 Max does not have a data type that can represent any number of arbitrary bytes , so this object uses a form of pointer.;
#P window setfont "Sans Serif" 14.;
#P comment 19 31 284 196622 How is the arbitrary binary data in a UDP packet represented in Max?;
#P window setfont "Sans Serif" 9.;
#P comment 31 82 266 196617 The UDP protocol sends around "packets" (a.k.a. "datagrams") , which are chunks of arbitrary binary data. The maximum packet size for UDP is 64K bytes.;
#P pop;
#P newobj 293 294 158 196617 p how-are-packets-represented?;
#P window linecount 2;
#P comment 291 227 175 196617 otudp write sends UDP packets to a given IP address and port number.;
#P window linecount 1;
#N vpatcher 221 270 567 724;
#P window setfont "Sans Serif" 9.;
#P comment 22 391 253 196617 OTUDP uses the same pool of packet buffers for both of these mechanisms.;
#P comment 22 278 253 196617 OTUDP versions 2. and above also use these buffers for outgoing data if you are using overdrive. MacOS 9.1 and higher do not allow UDP packets to be sent at interrupt time. So if you’re in overdrive OTUDP must copy your data into a temporary buffer and then wait until "deferred task time" , after all the interrupt handlers have finished , to actually output the data. You can avoid copying all the data in your packet by turning off overdrive.;
#P comment 22 211 253 196617 When lots of UDP packets come in before Max has a chance to process them , they build up in these receive buffers. After an otudp object runs out of receive buffers , it throws away all incoming packets until a buffer is freed.;
#P comment 22 49 253 196617 otudp versions 1.4 and above use OpenTransport in asynchronous mode (unlike earlier versions , which used OT in synchronous mode). This means that Open Transport informs otudp about incoming packets by calling a "notifier" function at interrupt level. The otudp object copies the incoming packet into one of its own internally-managed buffers , and then uses a "clock" to have Max schedule the output of the FullPacket message for this buffer at non-interrupt time. Then , after your patch has processed the packet (i.e. , after the chain of objects starting from the outlet of otutp all do their thing) , that receive buffer is reclaimed to use again.;
#P window setfont "Sans Serif" 14.;
#P comment 10 22 284 196622 What’s with these buffers?;
#P pop;
#P newobj 293 275 144 196617 p what’s-with-these-buffers?;
#N vpatcher 50 40 411 239;
#P window setfont "Sans Serif" 14.;
#P comment 11 22 312 196622 Even otudp write objects receive packets:;
#P window setfont "Sans Serif" 9.;
#P comment 17 47 303 196617 Part of the UDP protocol is that each packet has a return address , which consists of the IP address and UDP port number of the process that sent the packet. So whatever program you send UDP packets to with "otudp write" can send UDP packets back via this return address. That’s why "otudp write" also outputs "FullPacket" messages , just like "otudp read";
#P pop;
#P newobj 293 332 172 196617 p otudp-write-receives-packets-too;
#P window linecount 2;
#P comment 632 207 150 196617 Highly verbose dump of object’s state to the Max window.;
#P window linecount 1;
#P comment 313 90 204 196617 [port-number] (required);
#P comment 313 104 204 196617 nbufs [n] (optional – default is 20);
#P comment 313 118 204 196617 bufsize [nbytes] (optional – default is 1024);
#P comment 298 60 116 196617 udp write parameters:;
#P comment 313 75 204 196617 [IP-address] (required);
#P newex 31 213 105 196617 print not-too-exciting;
#P comment 33 89 231 196617 nbufs [n] (optional – default is 20);
#N picture;
#K replace 227;
#K set 0 46268416 48 7147777 16779776 0 805334432 8560640 -1902641138 0 3145837 0 3145837 0 3145837 755 390400 25149455 218627087 -2147467776 16252931 -520101873 219151903 -1073709312 33292295 -251662321 220200479 -536838400 66846735 -260050929 220199967 -268402816 66846751 -268374001 220069919 -268402816 66846782 -268374001 220069918 -134185088 129761342 -268374001 220069918 -134186112 129761404 -268374001 220069918 2080406464 129761404 -268374001 220069918 1006664640 129761528 -268374001 220069918 1040219072 255590640 -268374001 220069918 503347680 255590896 -268374001 220069918 520124896 255590880 -268374001 220069918 251689440 238814176 -268374001 220069918 260078048 507249600 -268374001 220069918 125860080 507250624 -268374001 220069918 130054384 507250560 -268374001 220069918 62945520 473698176 -268374001 220069918 65042672 1010568960 -268374001 220069918 31488120 1010573056 -268374001 220069918 15759480 1010572800 -268374001 220069918 15759480 943472128 -268374001 220069918 7895096 2017213440 -268374001 220069918 7895100 2017229824 -268374001 220069918 3962940 2017228800 -268374001 220069918 3962940 1883041792 -268374001 220069918 1996830 -264441856 -268374001 220069918 1996830 -264380416 -268374001 220069918 1013790 -264380416;
#K set 128 -268374001 220069918 522271 -532692992 -268374001 220200958 522255 -532692992 -4081 219152380 260111 -532709376 2147475471 218628088 126983 -1071710208 1073725442 -218103053 193280 49479682 -218103053 193280 252512240 1044480 535822367 -268427328 252511792 897024 464519196 1879054528 252511984 831488 422576153 805313984 252511984 864256 447741976 805313984 252511792 897024 464519195 -1342169664 252512240 1044480 535822367 -268427328 49479840 9412608 -2080440320 -2147483632 -2147483632 -2147483632 -2113929100 -2147483632 -2147483576 -2147483632 -2147483632 -2097151964 -2147483632 -1979711364 -2147483632 -2147483616 -2113929100 -2147483632 -2147483632 -2147483628 -2147483632 -2147483632 -1979711364 -2147483528 -2080374472 -2147483360 -2147483360 -2147483360 -2147483360 -2147483360 -2147483360 -2147483608 -2147483608 0 -2147483628 -2147483628 -2147483628 20 27290128 572653570 655477 206848103 40575216 40404084 -613566757 0 92014160 90514468 14540253 14540253 82721440 -1227133514 0;
#P vpicture 547 339 658 389;
#P message 543 207 85 196617 tellmeeverything;
#P newex 67 260 75 196617 print messages;
#P comment 33 103 231 196617 bufsize [nbytes] (optional – default is 1024);
#P newex 18 260 48 196617 print end;
#P newex 119 240 53 196617 print time;
#P newex 18 237 88 196617 OpenSoundControl;
#P newex 18 189 180 196617 otudp read 8000 nbufs 10 bufsize 256;
#P message 543 183 75 196617 errorreporting;
#P message 543 162 42 196617 version;
#N vpatcher 42 354 329 489;
#P window setfont "Sans Serif" 9.;
#P comment 1 54 254 196617 otudp is a PPC-only external. For 68K Macintoshes , you must use the "udp" object which does not use Open Transport. We may release a version that runs on 68K using OpenTransport.;
#P window setfont "Sans Serif" 14.;
#P comment 3 21 206 196622 OTUDP is for Power PC only;
#P pop;
#P newobj 293 351 58 196617 p PPC-only;
#P window setfont "Sans Serif" 14.;
#P comment 5 24 52 196622 otudp;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 60 22 198 196617 Send or receive data over ethernet using the UDP protocol , using Open Transport.;
#P window linecount 7;
#P comment 533 58 252 196617 The IP address can be either symbolic (as in foo.bar.com) or numeric (as in 23.24.25.26). Symbolic IP addresses require DNR "(Domain Name Resolution" , whereby your Mac talks to a "Domain Name Server" to translate the symbolic name into numbers) , so it may be safer to use numeric IP addresses.;
#P window linecount 1;
#N vpatcher 50 39 394 365;
#P window setfont "Sans Serif" 9.;
#P comment 8 186 321 196617 Atom arguments[2] ; SETLONG(&arguments[0] , numberOfBytesInMyPacket) ; SETLONG(&arguments[1] , (long) pointerToThoseBytes) ; outlet_anything(x->my_outlet , gensym("FullPacket") , 2 , arguments) ;;
#P comment 8 107 310 196617 Max does not provide any mechanisms to manipulate pointers to binary data , so you will probably either use CNMAT’s OpenSoundControl object , or write a similar external to implement your own protocol. Your external should prepare a contiguous buffer with the bytes you want to put in the UDP packet , then cast a pointer to that buffer to a long int. Here’s some example code:;
#P comment 8 63 310 196617 The "FullPacket" message to "otudp write" should have two int arguments: the number of bytes of the packet , and a pointer to those bytes , represented as a Max integer.;
#P comment 7 29 310 196617 The mechanism for getting binary data into "otudp write" has been much improved in version 1.4.;
#P comment 8 243 310 196617 For backwards compatibility , otudp still accepts the evil "write" and "gimme" messages that horribly abuse the meaning of Max’s argc/argv and crash your Mac if you use them wrong. Sorry ; I don’t know what we were thinking when we designed that.;
#P pop;
#P newobj 293 313 185 196617 p how-do-I-get-data-into-otudp-write?;
#P message 291 139 190 196617 message arg1 arg2 arg3 arg4 arg5 arg6;
#P newex 291 181 88 196617 OpenSoundControl;
#P newex 291 159 31 196617 t b s;
#P newex 291 203 204 196617 otudp write http://www.cnmat.berkeley.edu 7123;
#P comment 661 348 112 196617 otudp help version 0.8;
#P comment 550 146 187 196617 Some other stuff you can send to otudp:;
#P comment 632 162 149 196617 Print version info;
#P window linecount 2;
#P comment 632 178 150 196617 Toggle whether errors cause a message in the Max window;
#P comment 549 393 278 196617 OTUDP , and all other CNMAT Max objects , can be found at: http://www.cnmat.berkeley.edu/MAX;
#P window linecount 1;
#P comment 18 60 116 196617 otudp read parameters:;
#P comment 33 75 231 196617 [port-number] (required);
#P window linecount 3;
#P comment 14 284 257 196617 otudp read opens a port on your Mac to accept incoming UDP packets. Each otudp read object must have a unique port number.;
#P window linecount 2;
#P comment 662 244 100 196617 Change the host that this object writes to;
#P hidden connect 52 0 9 0;
#P hidden connect 50 0 9 0;
#P hidden connect 40 0 9 0;
#P hidden connect 19 0 9 0;
#P hidden connect 18 0 9 0;
#P connect 11 0 9 0;
#P hidden connect 26 0 9 0;
#P hidden connect 49 0 9 0;
#P connect 10 1 11 0;
#P connect 10 0 11 0;
#P connect 12 0 10 0;
#P connect 21 2 22 0;
#P connect 21 1 25 0;
#P connect 20 0 21 0;
#P connect 20 0 29 0;
#P connect 21 0 23 0;
#P connect 43 0 20 0;
#P connect 47 0 20 0;
#P window clipboard copycount 54;


Viewing 5 posts - 1 through 5 (of 5 total)