[mxj net.udp.send] to accept raw data (Art-Net development)


    Oct 28 2007 | 11:48 pm
    Hello List,
    Is there a way that [mxj net.udp.send] and [mxj net.udp.recv] send or
    receive data as raw-bytes (binary 0-255), as aka.datagram does?
    My problem is that I need to send/receive a list of 530 items and
    aka.datagram does not support this list size...
    Any ideas?
    Thanks very much for help.
    Philippe

    • Oct 29 2007 | 6:13 am
      On 29 oct. 07, at 00:48, Philippe Montemont wrote:
      > Hello List,
      >
      > Is there a way that [mxj net.udp.send] and [mxj net.udp.recv] send
      > or receive data as raw-bytes (binary 0-255), as aka.datagram does?
      > My problem is that I need to send/receive a list of 530 items and
      > aka.datagram does not support this list size...
      > Any ideas?
      > Thanks very much for help.
      could you post a patch? You could encode the value (8 bits), in 32
      bits to have shortest list.
      ej
    • Oct 29 2007 | 11:12 am
    • Nov 02 2007 | 1:59 am
      I'm having a big problem with this now. I need to send binary data to
      a non-Max receiver. I recoded net.udp.send simply to accept ints, put
      them in a DatagramPacket and send them on a DatagramSocket.
      Unfortunately, there appears to be a Java bug that causes it to drop
      packets every so often. I've only tested on my PB G4 Aluminum, in
      10.3.9, but plan to test on another machine to see if I get different
      results.
      Any other insight would be greatly appreciated.
      Eric
      At 12:48 AM +0100 10/29/07, Philippe Montemont wrote:
      >Hello List,
      >
      >Is there a way that [mxj net.udp.send] and [mxj net.udp.recv] send
      >or receive data as raw-bytes (binary 0-255), as aka.datagram does?
      >My problem is that I need to send/receive a list of 530 items and
      >aka.datagram does not support this list size...
      >Any ideas?
      >Thanks very much for help.
    • Nov 05 2007 | 10:40 pm
      Philippe, Eric,
      i had the same issue some time ago and could not find a way to send/
      receive raw bytes to/from a microcontroller
      using mxj net.udp.*
      so i made some classes that use DatagramSocket and DatagramPacket to
      send/receive byte-buffers.
      don't know what's going wrong with your examples, eric, but i didn't
      notice any dropped packets.
      if anybody is interested, you can find my early attempts here:
      my java knowledge is still quite limited... so any comments on how to
      improve those are welcome.
      volker.
      On 02 Nov 2007, at 02:59, Eric Singer wrote:
      > I'm having a big problem with this now. I need to send binary data
      > to a non-Max receiver. I recoded net.udp.send simply to accept
      > ints, put them in a DatagramPacket and send them on a
      > DatagramSocket. Unfortunately, there appears to be a Java bug that
      > causes it to drop packets every so often. I've only tested on my PB
      > G4 Aluminum, in 10.3.9, but plan to test on another machine to see
      > if I get different results.
      >
      > Any other insight would be greatly appreciated.
      >
      > Eric
      >
      > At 12:48 AM +0100 10/29/07, Philippe Montemont wrote:
      >> Hello List,
      >>
      >> Is there a way that [mxj net.udp.send] and [mxj net.udp.recv] send
      >> or receive data as raw-bytes (binary 0-255), as aka.datagram does?
      >> My problem is that I need to send/receive a list of 530 items and
      >> aka.datagram does not support this list size...
      >> Any ideas?
      >> Thanks very much for help.
    • May 28 2009 | 10:26 am
      i just got the enttec ODE (open dmx over Ethernet) which supports art-net, but seems i jumped the gun and there is no available external to handle it.
      aside of the commercial max environment known as lightRegie120 i haven't seen anyone interfacing it.
      the (dead)list suggest sending raw java packets of 512bytes - http://www.cycling74.com/forums/index.php?t=msg&goto=119425 - but this seems a lowly patching hack not taking care of compression and other stuff the spec has.
      i hate to be alone on this, and dmx is cool and vvvv has it internaly and everyone's happy. and im not
      fun reading for the archives-
      anyways, if someone has anything working pls let me know
    • May 29 2009 | 8:03 am
      yair r. wrote on Thu, 28 May 2009 12:26i just got the enttec ODE (open dmx over Ethernet) which supports art-net, but seems i jumped the gun and there is no available external to handle it.
      I'm working on one, but don't have a hardware box yet to test it on. Might take some time to get it finished since the project this is needed for is still some time away. Also, this would probably be another commercial external, so don't wait for it if you need something right now and for free.
      Olaf
    • May 29 2009 | 8:45 am
      thats great news, i would think cycling74 should take care of this as the convergence of video and lighting is the way things are going anyways. i got it working on another enviroement so its not super urgent. but i would certainly pay for it when your done.
      and please consider 4.6 xp users
    • May 29 2009 | 10:05 am
      i am currently working on a project, where i have to send raw
      bytes via udp.
      so i used volkers java external. thanx a lot for this
      it showed me the right direction !
      i also fixed a bug. at the original code the external
      always opened a new port if you send a list.
      after sending 20.000 lists the extenal crashed.
      here is the fixed code:
      have fun with it !
      will
      import com.cycling74.max.*;
      import java.net.*;
      import java.io.IOException;
      /*
      * Created on Jun 26, 2005
      * @author volker boehm
      * argument is port-number
      */
      public class UdpSendRaw extends MaxObject {
      public int port = 7777; // default port number
      public String host = "127.0.0.1"; // "localhost" - change this to the desired ip address
      private InetAddress servAddr;
      private byte[] buffer; // declare byte-buffer
      private DatagramSocket sock = null;
      private static final String[] INLET_ASSIST = new String[] {"(list) list of bytes to send"};
      private static final String[] OUTLET_ASSIST = new String[] {"bang when packet sent"};
      private void initSocket(){
      if ( sock == null ){
      try { sock = new DatagramSocket(); }
      catch(IOException e) {
      System.err.println(e);
      }
      }
      }
      public UdpSendRaw(Atom[] args) {
      declareIO(1, 1);
      createInfoOutlet(false);
      setInletAssist(INLET_ASSIST);
      setOutletAssist(OUTLET_ASSIST);
      if(args.length>0) {
      if(args[0].isInt())
      port = args[0].getInt(); // argument sets port number
      else {
      error("UdpSendRaw: argument should be port number (int)n--- setting to default port");
      port = 7777;
      }
      }
      post("UdpSendRaw: sending to "+host+" on port "+port);
      }
      public void list(int[] input) {
      int packSize = input.length;
      buffer = new byte[packSize];
      initSocket();
      // fill byte buffer
      for(int i=0; i buffer[i] = (byte)input[i];
      try {
      servAddr = InetAddress.getByName(host);
      // create UDP-Packet to send
      DatagramPacket packet = new DatagramPacket(buffer, packSize, servAddr, port);
      sock.send(packet);
      outletBang(0); // output bang when packet sent
      // sock.disconnect();
      }
      catch(IOException e) {
      System.err.println(e);
      }
      }
      // change port number
      public void port(int p) {
      port = p;
      }
      // change host address
      public void host(String s) {
      host = s;
      }
      }
    • May 29 2009 | 3:34 pm
      I'm sure I'm missing something, but shouldn't this all be possible with the right combination of
      udpsend
      itoa/atoi
      spell
      sprintf %x
      ?
      More thoughts on this would be helpful to hear, it's been a struggle in the past for me too. Interfacing with DMX devices should be simple, the stumbling block seems to be the formatting. Once you've got that you can pump channel lists so easily from your pretty multisliders and tables...
    • May 30 2009 | 3:54 pm
      im trying the java class, it doesn't bodge my lights.
      i ran it thru wireshark (network sniffer with artnet protocol detection) and it complain the data packet is art-net, but malformed.
      i guessed it was because the help file example doesn't send a valid 512 length packet. because the 4.6 limit of 256 to message, i hacked the class to add trialing 0 to fill it up (made the buffer array a set length of 512). it is still "malformed".
      compared to a valid art-net frame length it is missing some bytes. formatting does seem to pose the challenge.
    • May 30 2009 | 5:14 pm
      to seejayjames:
      the problem ist, that udpsend does not send only the data.
      it always sends a kind of header which contains the information of the datatypes (int float etc.) you can easyly check this with a network sniffer. i prefere CocoaPacketAnalyzer.app
      to yair r.
      if you need more than 256 bytes, you could use a jitter matrix inside the mxj object.
      at my current project i am sending 537 bytes 1.200 times a second
      without problems. inside the mxj i convert a jitter matrix to a raw udp bytestream. so there should be no limit with the max listsize.
      but i am using max 5.0.7.
      hope it helps,
      will
    • May 30 2009 | 6:59 pm
      Quote:inside the mxj i convert a jitter matrix to a raw udp bytestream. so there should be no limit with the max listsize.
      will76, I've been doing this with aka.datagram and jit.iter. This usually works.. ok, but I have found some limits to what it can do. Curious if you've found any sort of performance hit going to java from maxland.
    • May 30 2009 | 8:29 pm
      hey scott,
      dont know, if it is the fastes way or not ...
      for my installation its fast enough.
      i am also interested in other, (perhaps faster) ways
      of stripping the pixel information from a matrix and
      sending the raw bytes via udp.
      perhaps the next instalation has bigger dimensions
      what object are you useing for sending the data without using java ?
      will
    • May 31 2009 | 6:45 am
      ok, following will76 advice, i used a [jit.matrix 1 char 512] > [jit.spill @listlength 512]
      reading the visua basic source i linked above to comply with art-net spec we need to add a 17 byte header, like
      ' send a DMX packet to 'Universe', dmx is in a byte array 'Data' and the DataLength also is required
          Public Sub SendDMX(ByVal Universe As Int16, ByVal Data() As Byte, ByVal DataLength As Int16)
      
              ' this constant defines the length in bytes of the header info of the
              ' OpOutput packet
              Const HeaderLength = 17
      
              ' prepare a buffer of the correct length
              Dim buf(HeaderLength + DataLength) As Byte
      
              ' copy the header 'Art-Net ' into the buffer
              Buffer.BlockCopy(ArtNetHead, 0, buf, 0, ArtNetHead.Length)	' Ascii "Art-Net" & 0 == ArtNetHead() As Byte = {65, 114, 116, 45, 78, 101, 116, 0}
      
              ' op code
              buf(8) = LoByte(OpOutput)  ' dmx output
              buf(9) = HiByte(OpOutput)	'Private Const OpOutput As Short = &H5000S
      
              ' version (two bytes)
              buf(10) = 0
              buf(11) = ProtocolVersion  'Private Const ProtocolVersion As Short = 14
              'sequence
              buf(12) = 0
              'physical
              buf(13) = 0
              ' universe (two bytes)
              buf(14) = LoByte(Universe) '== 00
              buf(15) = HiByte(Universe) 	'== 00
              ' data length (two bytes, note: manual byte-swap!)
              buf(16) = HiByte(DataLength) ' data length 1 - 512
              buf(17) = LoByte(DataLength) ' data length
      
              Try
                  ' now copy in the dmx data
                  Buffer.BlockCopy(Data, 0, buf, 18, DataLength)
      
              ' broadcast the newly formed Art-Net packet
              UDP_Send(BroadcastAddress, DefaultPort, buf)
          End Sub
      assuming were using default header (universe=0 length=512) we need to add the following byte code before the 512 data.
      byte[] header = {41 72 74 2d 4e 65 74 00 00 50 00 0e 00 00 00 00 02 00}
      (for understanding, 41 72 74 2d 4e 65 74 00 is ascii for Art-Net, see [spell]>[sprintf %x])
      this is in byte and wont compile in the java external, i'll try later to convert to int and back to byte.
    • May 31 2009 | 7:54 am
      Quote:what object are you useing for sending the data without using java ?
      I use aka.datagram with udpsend. A stripped down example is below
      I've been able to push a large number of bytes this way, but always looking to move more. I think the real bottleneck here is jit.iter. It can really chug when trying to spit out large numbers of matrices.
    • May 31 2009 | 10:49 am
      hey scott,
      you are totaly right ! it is possible without java.
      i thought i tryed that ...
      if i have time i will post a performance comparison
      between jit.iter/ aka.datagram and the java solution.
      thanks a lot for your advice and have a nice day !
      if you send 1 2 3 4 5 6 7 8 9 10 via udpsend you get
      the following results:
      with aka.datagram
      00000 01 02 03 04 05 06 07 08 09 0a
      without aka.datagram
      00000 6c 69 73 74 00 00 00 00 2c 69 69 69 69 69 69 69 list....,iiiiiii
      00010 69 69 69 00 00 00 00 01 00 00 00 02 00 00 00 03 iii.............
      00020 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 ................
      00030 00 00 00 08 00 00 00 09 00 00 00 0a ............
    • May 31 2009 | 10:01 pm
      well, got it working.
      header formatting was strangely satisfying. placed the header in front of the udp byte array, thus making it into a valid art-net packet. the java could be better. this is only for sending valid art-net packets.
      based on the java class discussed above (thanks guys), so should be windows and mac compatible.
      yair reshef
      art2please.com
    • May 31 2009 | 10:25 pm
      hey yair,
      thanx for sharing your code
      but you dont have to define the buffer
      every time you send the list.
      change
      private byte[] buffer; // declare byte-buffer
      to
      private byte[] buffer = new byte[537];
      and delete:
      buffer = new byte[537];
      will
    • Jul 11 2009 | 4:58 pm
      here is a test i did with the artnet protocol to move a small led light wash, replacing the element with a camera for some HDR panorama time-lapsing.
      (hopefully will be up in an hour or so)
    • Sep 09 2009 | 6:38 pm
      Yair,
      I'm having some trouble with the ARTnet send receive you build.
      I'm not a good coder in java and have no clear way what is wrong except that I imagine that the java version isn't what it supposed o be:
      java.lang.UnsupportedClassVersionError: Bad version number in .class file
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
      at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:119)
      at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
      Could not load class 'UdpRecvRaw'
      java.lang.UnsupportedClassVersionError: Bad version number in .class file
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
      at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:119)
      at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
      Could not load class 'UdpSendRaw'
      any ideas on how to fix this? I updated to 10.5.6 do I need an even more updated os?
      best
      pieter
    • Sep 09 2009 | 6:59 pm
      i'll check it later tonight.
      it does look like a java version mess and if it is i (probebly) cant help.
      as i recal my help file was not very helpfull so i'll start with that.
      btw. you know it is only for sending? the reciving part i didnt code as i had no dmx inputs to use...
      best, yair
    • Sep 09 2009 | 7:03 pm
      i just need it to run an installation that normally uses a lanbox, but we haven't got one anymore, so only sending is ok.
      Thanx heaps
      Pieter
    • Sep 11 2009 | 8:36 am
      Yair,
      we recompiled it and now I think it works, although I get following errors (which I don't have a clue about):
      java.lang.NoClassDefFoundError: com/cycling74/jitter/JitterObject
      Could not load class 'com/cycling74/jitter/JitterObject'
      could not find jitter.jar
      (mxj classloader) dynamic classpath entry /Users/llumen/Desktop/classes/ does not exist.
      UdpRecvRaw: binding to port: 6454 ***
      *** max. packetSize: 4096 ***
      UdpSendRaw: sending to 255.255.255.255 on port 6454
      best
      pieter