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