Hi Calude,

I don't know if mrpeach osc and net objects work on Windows, but if they do they should be preferred to the OSCx objects. (snip) OSCx library is old, buggy, unmaintained, broken

I've tried the two libraries prior to my post. They both work well on Windows to the extent that I saw neither having disadvantages over the other.

(Not to say that I intend to ignore warnings on avoiding OSCx.. just mentioning it for historical logging.)

A problem I see commonly among the two mentioned sets of libraries is that they output incorrect values when receiving float or negatives. Integers and zero are fine.

Can anyone share experience or workarounds before I go reinvent some more wheels?

Hi Martin,

Thank you for your response.

I am attaching the patch used to produce the following results.

This was tested on Pd version 0.41.4-extended, running on WinXP SP3.

The OSC data were sent by GlovePIE running the following code.

SendOSC("127.0.0.1", 9997, "/test", 0) wait 1 second SendOSC("127.0.0.1", 9997, "/test", 1.5) wait 1 second SendOSC("127.0.0.1", 9997, "/test", -1) wait 1 second

I was expecting [routeOSC] to output 0, 1.5, -1.

--- Output ---

raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 unpacked: /test 0 routed: 0

raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 63 0 0 unpacked: /test 0.746094 routed: 0.746094

raw: 47 116 101 115 116 0 0 0 44 105 0 0 63 63 63 63 unpacked: /test 1.06111e+009 routed: 1.06111e+009

Thank you again for your help.

Hi Martin,

So it seems like a problem with GlovePIE not formatting the bytes according to the OSC specs..

I will review the format and if find it relevant, contact the author.

Thanks again for investigating.

Hi,

i tried your patch on winxp just with udpsend and had the same problems: error: udpsend_send: item 0 (-1.000000) is not between 0 and 255 error: udpsend_send: item 0 (1.100000) is not an integer so maybe the problem is not OSC but UDP? as it seems to handle only single bytes. So my question how to send a -1.1 over UDP? g.

PSPunch schrieb:

Hi Martin,

Thank you for your response.

I am attaching the patch used to produce the following results.

This was tested on Pd version 0.41.4-extended, running on WinXP SP3.

The OSC data were sent by GlovePIE running the following code.

---

SendOSC("127.0.0.1", 9997, "/test", 0) wait 1 second SendOSC("127.0.0.1", 9997, "/test", 1.5) wait 1 second SendOSC("127.0.0.1", 9997, "/test", -1) wait 1 second

---

I was expecting [routeOSC] to output 0, 1.5, -1.

--- Output ---

raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 unpacked: /test 0 routed: 0

raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 63 0 0 unpacked: /test 0.746094 routed: 0.746094

raw: 47 116 101 115 116 0 0 0 44 105 0 0 63 63 63 63 unpacked: /test 1.06111e+009 routed: 1.06111e+009

Thank you again for your help.

---

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

hi,

thanks a lot - that made it clear to me. g.

IOhannes m zmoelnig schrieb:

Georg Werner wrote:

...

Hi,

i tried your patch on winxp just with udpsend and had the same problems: error: udpsend_send: item 0 (-1.000000) is not between 0 and 255 error: udpsend_send: item 0 (1.100000) is not an integer so maybe the problem is not OSC but UDP? as it seems to handle only single bytes. So my question how to send a -1.1 over UDP? g.

haven't looked at the patch, but there are two possible reasons for this:

• somebody (the patch?) is injecting non-byte-values into the data to

udpsend. udpsend takes a list of bytes, not a Pd message. this means: you cannot just send the message "/test -1" to udpsend, you need an object inbetween that translates the message "/test -1" into a binary format. [packOSC] is one such object which will translate the given message into a list of bytes "47 116 101 115 116 0 0 0 44 105 0 0 255 255 255 255" (all atoms are floats and the values are integer and between [0, 255]). [udpsend] is NOT a drop-in replacement for [netsend 1]!

• very old(!) versions of [udpsend] (or was it [udpreceive]?) had a

problem with signed/unsignedness, resulting in "255" (binary 11111111 in unsigned) being interpreted as "-1" (binary 11111111 in signed). if this is the case, you have to upgrade udpsend/receive (e.g. install a newer stable release of Pd-extended)

gfmasdr IOhannes