Scott Fitzgerald

I'm sending a 9 byte packet from net.udp.send. I'm grouping the ascii

bytes together before sending them out, dropping it in a [tosymbol]

with no separator (otherwise a space gets stuck in between each one).

However, at the tail end of the packet, I'm seeing a trailing byte for

I'm expecting to see (in my packet sniffer) : f1 01 04 31 50 4c 0d df f2

but am instead seeing : f1 01 04 31 50 4c 0d df f2 20

Is this expected? Is there a way around this? I've included a patch below.

I'm sending a 9 byte packet from net.udp.send.  I'm grouping the ascii
bytes together before sending them out, dropping it in a [tosymbol]
with no separator (otherwise a space gets stuck in between each one).
However, at the tail end of the packet, I'm seeing a trailing byte for
a total of 10, not 9.

I'm expecting to see (in my packet sniffer) : f1 01 04 31 50 4c 0d df f2
but am instead seeing : f1 01 04 31 50 4c 0d df f2 20

Is this expected? Is there a way around this?  I've included a patch below.

extra-byte-at-the-end-of-mxj-net-udp-send

net.udp.send converts the input it gets into a String and sends that.

So I'm actually surprised that sending it a list of 9 byte-sized

integers worked out the way you expected it to - I would have expected

each character in the String representation of that list to be a byte

> I'm sending a 9 byte packet from net.udp.send. I'm grouping the ascii

> bytes together before sending them out, dropping it in a [tosymbol]

> with no separator (otherwise a space gets stuck in between each one).

> However, at the tail end of the packet, I'm seeing a trailing byte for

> I'm expecting to see (in my packet sniffer) : f1 01 04 31 50 4c 0d df f2

> but am instead seeing : f1 01 04 31 50 4c 0d df f2 20

> Is this expected? Is there a way around this? I've included a patch below.

> #P message 176 224 47 9109513 separator;

> #P newex 128 171 48 9109513 zl group 9;

> #P newex 90 97 133 9109513 t 242 223 13 76 80 49 4 1 241;

> #P newex 129 284 243 9109513 mxj net.udp.send @address 129.228.159.66

net.udp.send converts the input it gets into a String and sends that.
So I'm actually surprised that sending it a list of 9 byte-sized
integers worked out the way you expected it to - I would have expected
each character in the String representation of that list to be a byte
of its own.

On 7/19/06, Scott Fitzgerald  wrote:
> Hi all,
>
> I'm sending a 9 byte packet from net.udp.send.  I'm grouping the ascii
> bytes together before sending them out, dropping it in a [tosymbol]
> with no separator (otherwise a space gets stuck in between each one).
> However, at the tail end of the packet, I'm seeing a trailing byte for
> a total of 10, not 9.
>
> I'm expecting to see (in my packet sniffer) : f1 01 04 31 50 4c 0d df f2
> but am instead seeing : f1 01 04 31 50 4c 0d df f2 20
>
> Is this expected? Is there a way around this?  I've included a patch below.
>
> Thanks for your help!
>
> ~scott
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 176 224 47 9109513 separator;
> #P newex 129 193 27 9109513 t l b;
> #P newex 126 248 47 9109513 tosymbol;
> #P newex 128 171 48 9109513 zl group 9;
> #P button 92 64 15 0;
> #P newex 90 97 133 9109513 t 242 223 13 76 80 49 4 1 241;
> #P newex 128 139 40 9109513 itoa;
> #P newex 129 284 243 9109513 mxj net.udp.send @address 129.228.159.66
> @port 2639;
> #P connect 5 0 0 0;
> #P connect 1 0 4 0;
> #P connect 6 1 7 0;
> #P connect 4 0 6 0;
> #P connect 2 0 1 0;
> #P connect 2 1 1 0;
> #P connect 2 2 1 0;
> #P connect 2 3 1 0;
> #P connect 2 4 1 0;
> #P connect 2 5 1 0;
> #P connect 2 6 1 0;
> #P connect 2 7 1 0;
> #P connect 2 8 1 0;
> #P connect 7 0 5 0;
> #P connect 6 0 5 0;
> #P connect 3 0 2 0;
> #P window clipboard copycount 8;
>


hm. That presents a problem for me since I'm comminucating with an

external device that has a fixed protocol (none of this all max

patches goodness going on here, sadly). Any sugestions on what I can

do to send out the bytes as listed? Typically I use aka.datagram on

OSX, but I'm stuck in windows for this. I was hoping for an out of

the box solution, but if none exists i'll dig into the java...

> net.udp.send converts the input it gets into a String and sends that.

> So I'm actually surprised that sending it a list of 9 byte-sized

> integers worked out the way you expected it to - I would have expected

> each character in the String representation of that list to be a byte

hm.  That presents a problem for me since I'm comminucating with an
external device that has a fixed protocol (none of this all max
patches goodness going on here, sadly).  Any sugestions on what I can
do to send out the bytes as listed?  Typically I use aka.datagram on
OSX, but I'm stuck in windows for this.   I was hoping for an out of
the box solution, but if none exists i'll dig into the java...

On 7/19/06, Ben Nevile  wrote:
> Hi Scott,
>
> net.udp.send converts the input it gets into a String and sends that.
> So I'm actually surprised that sending it a list of 9 byte-sized
> integers worked out the way you expected it to - I would have expected
> each character in the String representation of that list to be a byte
> of its own.
>


On 20 Jul 2006, at 14:26, Scott Fitzgerald wrote:

> the box solution, but if none exists i'll dig into the java...

I have a quickly-hacked-up UDP packet receiver written as an MXJ 

object; my plan is to tidy it up and make it part of a suite of OSC 

tools, so you're free to (i) wait until I've done that, or (ii) have 

a copy of the source of the existing MXJ object. You'll need to know 

some Java to work with the embedded bytes, but it shouldn't be hard.

nick rothwell -- composition, systems, performance -- 

> I was hoping for an out of
> the box solution, but if none exists i'll dig into the java...

I have a quickly-hacked-up UDP packet receiver written as an MXJ  
object; my plan is to tidy it up and make it part of a suite of OSC  
tools, so you're free to (i) wait until I've done that, or (ii) have  
a copy of the source of the existing MXJ object. You'll need to know  
some Java to work with the embedded bytes, but it shouldn't be hard.

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


extra byte at the end of mxj net.udp.send?