Ethernet <> serial <> MB ?

[Rowan]

Hi,

I came across this today:

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=7623833837&ssPageName=MERC_VI_ReBay_Pr4_PcY_BIN_Stores_IT

Does anyone have an idea if this could be used with MIOS to send MIDI Via Ethernet?

I know ethernet modules have been discussed before, but this seems like it could be a simple solution if MIOS and the computer at the other end can talk to it.

Regards

Rowan

[stryd_one]

That thing would make it soooo easy... OSC over UDP or MIDI over TCPIP (as opposed to MIDI over Ethernet, which doesn't use an IP stack) would be a snap... But the low baudrate could introduce timing problems, it'd be like using a 90% full pipe.

Pretty costly too, I'd hate to buy one and find out it won't work :( Do they do samples? ;)

[tos]

OSC...sigh.....

[MRE]

It would certainly work.. with a bit of programming on the PC side...

Honestly I think it makes more sense though to integrate USB using a Serial/USB adaptor. Literally plug and play.

[stryd_one]

USB and ethernet are fairly different in application though. Not really the same functions and capabilities.

Personally, I like good-old fashioned MIDI.  :)

[Rowan]

I'm going to look further into this when time permits. If the unit is bonjour friendly some very cool things could be done with Logic 7.

This seems like one for the Apple guys (audiocommander, what are your thoughts on this?) out there as

OSX.4 has MIDI over Ethernet built in (I don't know yet if ethernet is the right term in this case, maybe UDP) It all uses bonjour which is now available for window.

[johnh]

This seems like one for the Apple guys (audiocommander, what are your thoughts on this?) out there as

OSX.4 has MIDI over Ethernet built in (I don't know yet if ethernet is the right term in this case, maybe UDP) It all uses bonjour which is now available for window.

Like MIDI, ethernet is both a hardware specification and a software specification.  UDP is a protocol that runs on top of IP which is a protocol that runs on top of ethernet as well as other transports (serial lines, etc). TCP is another protocol that runs on top of IP.  So if you say TCP/IP you should say UDP/IP as well.  If you say TCP then you can say UDP.  On the wire (ethernet) you'll find ethernet packets that contain ip packets that contain udp or tcp packets.  Without knowing exactly how Apple implemented MIDI over the network it's hard to saw what the proper term is. 

TCP provides a mechanism for insuring that packets arrive at their destination.  UDP does not and leaves it up to the application to implement retries and error handling.  I'd be curious to know the details of Apple's implementation.

[Rowan]

Thanks Johnh, that clears thins up a bit.

I'm digging through the developer documentation at the moment to find some more details.

The info should be here, somewhere: http://developer.apple.com/audio/

or here: http://developer.apple.com/networking/

I just have to find the details

[MRE]

As with everything show related, timing is everything.

Let me use an analogy to the lighting world:

I know that when Ethernet DMX came out, there was a lot of fussing before hand about how to assure that the packets arrived on time, and in sequence, as TCP/IP/UDP can and will send them out of order when collisions occure.

The end result was: Yes, EthernetDMX works fantastic. It is fast enough that even with dropped packets comming in last, you didnt notice it much... So long as you 1: Have a dedicated network, and 2: only have one 'Host." I.e the DMX dimmers acted in a way like slaves, in that they would not generate their own traffic without requests. So, having one PC (managing the network), one or two 'Desk consoles' and a bunch of dimmers, and everything is perfect. Change things around, add more desktops..  and latency started to become apparent.

At least, on the DMXnet I worked with that was the case. Obviously replacing hubs with switches fixes just about all the problems. Again though, cant stress enough how important it is to keep it a dedicated network. As soon as lil' Billy goes browsing for porn, the lights start acting up.

How that translates to MIDI over Ethernet, I dont know. Scale is different. Three or four MIDI devices is not like 400+ lights (each a single ethernet node). However, lights only need one parameter (in the case of intelligent lights, no more than 16 usually) while MIDI can transfer a lot more information than just one byte to a single device.

I would also assume you are not attempting to download the latest Jenna Jameson video while making music ;)

Honestly, Ethernet DMX is a LOT of overhead for very little information. Remember that TCP has a minimum packet size. a single DMX channel only needs a single byte to describe its setting. A bank dimmer may have 8 or even 16 lamps on it, but still, at 16 bytes, there is still a lot of padded zeros in an EthernetDMX packet. Waste of overhead and processing power in my opinion. The only thing it solves is the 'world' system in which a DMX line is limited to 512 devices. An intelligent light might take up several 'devices'. It is easy to see that no more than 16 smart lights can exist on a dmx512 system. In large spaces, you might have to run several DMX systems if you have a lot of intelligent lighting. Thus ethernet comes into play in large arenas, since it is virtually unlimited as to how many devices can play. Not to mention, if one dimmer dies, the whole world doesn't fail (as is the case with DMX).

Again, how that translates to MIDI... well really it is just a lot of overhead and wasted power on relatively small timed packets of data. The logical progression to me is more along the lines of USB. Much less overhead, still lots of device room. Simple interconnect. Simple protocol.

I say leave Ethernet to what it is designed for: Connecting desktops to desktops .. transfering large chunks of data quickly, but without regard to packet order.

Serial to USB adaptors are incredibly cheap, and offer the data from the serial port side to the PC as if it were a REAL serial port. Essentially NO extra programming needs to be done, nor is there much overhead. A simple driver install fools every piece of software you have into thinking it is talking to a serial port.

[MRE]

Thanks Johnh, that clears thins up a bit.

I'm digging through the developer documentation at the moment to find some more details.

The info should be here, somewhere: http://developer.apple.com/audio/

or here: http://developer.apple.com/networking/

I just have to find the details

"Many MIDI drivers can simply be user-side I/O Kit clients (probably for serial,

USB, Firewire). PCI card drivers will need their MIDI drivers to communicate

with a separate Kernel extension."

After a brief look, I dont really see mention of Midi over Ethernet. Again, I don't really see the point anyway. If you had several laptops hooked together running virtual synths.. maby that would make sense.

[Silverfish]

Have you guys checked out the OSC page? http://www.opensoundcontrol.org/ Maybe it'll have some useful info. I know OSC sounds like a great idea, but I have a hard time coming up with a list of things that use the protocol.

[stryd_one]

I know OSC sounds like a great idea, but I have a hard time coming up with a list of things that use the protocol.

Exactly. It seems sometimes that this protocol is implemented only for the sake of saying that it's there.

Maybe in a few years time it might be relevent, but for those of us running lots of outboard and doing very little (if anything) 'in the box', it's irrelevant, and probably always will be.