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

Jul 19, 2006 at 9:16pm

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

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;

#26857
Jul 19, 2006 at 9:45pm

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.

Ben

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;
>

#80789
Jul 20, 2006 at 12:26pm

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…

thanks

~s

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.
>

#80790
Jul 20, 2006 at 12:39pm

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

> 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.

– N.

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

#80791

You must be logged in to reply to this topic.