Forums > MaxMSP

MIDI via UDP…? (max data types)

September 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 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, , 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.

T


September 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

http://opensoundcontrol.org/spec-1_0

(notice that using dumpOSC makes sense only when actually sending OSC messages)


September 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…

T


September 30, 2011 | 11:43 pm

Hi,

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


October 1, 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


October 1, 2011 | 2:10 am

thanks Adam, Macciza– you’ve put me on the right path.

Terry


October 1, 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

Terry


October 1, 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.

– Pasted Max Patch, click to expand. –

October 1, 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 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!


October 1, 2011 | 10:07 pm

You’re welcome! ;-)
If you ran into any trouble using these objects, please let me know.
Best,
Ádám


October 1, 2011 | 11:37 pm

Hi
On Mac MIDI Monitor will show network midi data . . .

Cheers
MM


Viewing 11 posts - 1 through 11 (of 11 total)