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


    Jul 19 2006 | 9:16 pm
    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

    • Jul 19 2006 | 9:45 pm
      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; >
    • Jul 20 2006 | 12:26 pm
      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. >
    • Jul 20 2006 | 12:39 pm
      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:// www.cassiel.com