MIDI via UDP...? (max data types)

    Sep 30 2011 | 11:43 am
    Well I've searched the forums and done a little bit of diagnostics. So now I'm posting here.
    I've got someone who wants me to send them MIDI via UDP. They won't be receiving the MIDI within Max. The first thing I did to test was: (144 24 127)->[udpsend 8080] and of course it works if receiving via Max ie [udpreceive 8080]->whatever.
    but if I use cnmat's dumpOSC (in verbose mode), I get:
    28 byte message: 6c (l) 69 (i) 73 (s) 74 (t) 0 () 0 () 0 () 0 () 2c (,) 69 (i) 69 (i) 69 (i) 0 () 0 () 0 () 0 () 0 () 0 () 0 () ffffff90 (?) 0 () 0 () 0 () 18 () 0 () 0 () 0 () 7f ()
    list 144 24 127
    So, obviously the ints are sent as 32-bit words (last 3 lines). I'm not sure what the ffffff in the 3rd last line is all about by the way. This data is also prepended with the string "list", then 4 zeros, then the chars ", i i i" 4 more zeros, then the actual MIDI data, but in the 32-bit long format.
    The "list" string is evidently generated by Max as an array identifier, then the null word, then the weird ",iii" string. Is this stuff to do with packet framing? All I can think of is the ",iii" is saying the next three words should be interpreted as ints, which means it would presumably be part of the UDP packet spec.
    My question is how do you get rid of all this stuff so it's just MIDI? You know, , not "list", NULL, ",iii", NULL, 0 0 0 byte, 0 0 0 byte, 0 0 0 byte
    Or do I actually _need- to get rid of it... does anyone know if there is a "MIDI vai UDP" protocol? If so what is it or where can I glean more information? Sorry if this is a naive question, but I've never done UDP stuff before.

    • Sep 30 2011 | 2:55 pm
      There is no MIDI via UDP protocol, but MIDI can easily be represented by OSC messages.
      The OSC format is explained here
      (notice that using dumpOSC makes sense only when actually sending OSC messages)
    • Sep 30 2011 | 11:35 pm
      Hi broc, for reasons beyond my control, I can't use OSC. Let me assure you I have tried to explain to the client that OSC is the way. So i'm stuck with MIDI over UDP.
      I know that the list I'm sending is prepended by the string "list" and the 4 bytes 2c (,) 69 (i) 69 (i) 69 (i), as this also shows up using netcat. Evidently a max data-type.
      I need to know how to get rid of this stuff and also how to (if possible) send the 4-byte words as single bytes.
      When I get a chance I'll try sending the list as a stream of iterated ints and see what happens...
    • Sep 30 2011 | 11:43 pm
      if you need to send raw bytes through UDP (or TCP), why not using [sadam.udpSender] (or [sadam.tcpSender]) from The sadam Library? You can access it here: http://www.sadam.hu/en/software .
      Hope that helps, Ádám
    • Oct 01 2011 | 12:07 am
      Hi There are MIDI protocols for what you want to do - RTP MIDI . . .
      Several turnkey systems and build-your-options available as well . . . ipMIDI, netmidi - many others too
      Try a net search on MIDI over udp . . If you are on a current Mac all you need to do is set up Network MIDI
      Cheers MM
    • Oct 01 2011 | 2:10 am
      thanks Adam, Macciza-- you've put me on the right path.
    • Oct 01 2011 | 4:52 am
      Hi Adam, I've tried sending raw bytes using your [sadam.udpSender], and can verify using your [saddam.udpReceiver], but if I use [udpreceive] to further verify I get error messages. Also I cannot seem to verify what's being sent by listening via netcat (unix command nc).
      Are you able to explain why only your [saddam.udpReceiver] understands messages sent by [sadam.udpSender]? I thought netcat at least would be able to hear what is sent. Evidently there is some formatting I need to do to make it more generic, or adhere to the udp protocol. Is this correct?
      thanks in advance
    • Oct 01 2011 | 10:53 am
      Hi Terry,
      as [udpreceive] is expecting data to be sent using the OSC format, it is expected to get an error if you send it data with the [sadam.udpSender], as the latter is sending a raw byte stream without any specific formatting. However, you're correct, netcat shouldn't give you an error (and it does not give any to me). Could you please let me know what error you are getting exactly and submit a small patch and the nc parameters that gave you that error?
      Thanks, Ádám
      P.S. Here is a very simple test patch. With netcat, I was using the commands nc -l 12345 for TCP and nc -l -u 12345 for UDP.
    • Oct 01 2011 | 3:26 pm
      the nc udp command you gave doesn't work for me:
      Terry-G5:~ Terry$ nc -l -u 12345 UDP listen needs -p arg Terry-G5:~ Terry$ nc -l -u -p 12345 Can't grab with bind
      this is the error message I was getting before
      but after mucking about with nc arguments I get: Terry-G5:~ Terry$ nc -l -u -vv -s -p 12345 listening on [] 12345 ... connect to [] from localhost [] 49510 UDP: Hello World!
      so your external works... (of course). Its just me not knowing how to use netcat properly
      I think I'll give up on netcat as a verification tool as it only reports bytes within the ascii character range, and interprets them as ascii characters, which is meaningless for MIDI.
      The good thing about dumpOSC (even though it doesn't work for my purposes) is that it's a persistent listener.
      But I think I can trust your [sadam.udpSender] and just start patching.
      Thanks very much!
    • Oct 01 2011 | 10:07 pm
      You're welcome! ;-) If you ran into any trouble using these objects, please let me know. Best, Ádám
    • Oct 01 2011 | 11:37 pm
      Hi On Mac MIDI Monitor will show network midi data . . .
      Cheers MM