MIDI via UDP…? (max data types)
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 127.0.0.1 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,
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.
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)
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…
if you need to send raw bytes through UDP (or TCP), why not using
[sadam.tcpSender]) from The
sadam Library? You can access it here: http://www.sadam.hu/en/software .
Hope that helps,
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
thanks Adam, Macciza– you’ve put me on the right path.
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
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?
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.
----------begin_max5_patcher---------- 387.3ocyTsraCBCD7L7UrxmSiX4Qf1a8anGqhpbvtItBrQXiZZix+dwFPgzl zfTipxAuFO6t1iGF4c9djUpsbMAd.dF7714644fr.d8q8Hkzs4ETsqLRIWqo q4jYc4L7sFGdVBrHCxBfjLHJDRCAL.aGYcCDsnYotuPLtOS.DE0NAXzvFJaJ ExBtwcZgG.UMlATrG8UkznEexcXgyC5g6pz7QEu6dQHvx9TU0bMWZnFgR9RM O2zUAhsMCoKrwf9vgdnl7MB45w0m3p2EiRirSX1nVDLmjnV81cgKHiXqjV5H E4wZAsfXSr222FlMQ4Wxeuca+g5qoLZ47FV0SbIiWCEpbZwFk1zJLQwImTbw qh3JjFxk0JLna5dmFGFbFwJ85JVm0qFCKRu48pmUKmhuCw+QemI+V02E2a6B +Ma2DkJWqjBg76OX5NcK9w5mV0TmOP2g2BfCLfw0Fgz8Vz3hROpnMBFi6xOn DkBVkp812SBX4I+aNUNY8IWjS3efRsK16+UOXb2v -----------end_max5_patcher-----------
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 0.0.0.0:12345 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 127.0.0.1 -p 12345
listening on [127.0.0.1] 12345 …
connect to [127.0.0.1] from localhost [127.0.0.1] 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!
You’re welcome! ;-)
If you ran into any trouble using these objects, please let me know.
On Mac MIDI Monitor will show network midi data . . .