Node Addressing and UDP Protocols

Note: multicasting/broadcasting is discussed here in simplified terms for the sake of clarity.

UDP can support unicasting (sending datagrams to a specific destination host) but more commonly multicasting is used (sending datagrams to all hosts on a given LAN or subnet). By contrast, TCP always sends data to exactly one destination host.

This allows UDP to act like a giant THRU box for MIDI, or even a MIDI routing matrix. However, it also raises a problem: if a particular host is both sending and receiving UDP traffic on a given port – how does it distinguish its own transmissions from the messages sent by other hosts?

DMIDI and NetMIDI use different solutions for this problem. The DMIDI specification provides for a four-octet Node Address, and ignores datagrams sent to other addresses. A Node Address is very similar to a SysEx Manufacturer ID, except that it allows up to a four byte identifier (SysEx IDs are either one or three 7-bit bytes in length). In fact, actual MMA SysEx Identifiers are used when a DMIDI Node serves a hardware sampler (e.g. when a node serves an Akai S1000 sampler, the node ID should be, 47:48:00:00). The DMIDI specification states:

"Software devices should avoid using pre-existing MIDI hardware node names unless they are intended to emulate the functions of the device. Software devices should use node names greater than 0x80. Popular software DMIDI devices should disseminate their node names to avoid duplicates."

It’s not clear whether DMIDI supports more than one instance of a given device type within the same network, because device type and node ID are apparently synonomous. It may be possible to use the least significant octet of the 4-octet Node ID to distinguish multiple instances of a single device type (up to 256 of each type within a single network). The current DMIDI specification is unclear.

NetMIDI provides considerably more flexibility:

  • Each NetMIDI node (port) disambiguates its own transmissions from those of other nodes through use of a SenderID number. This is a 32 bit value typically set from the CPU performance counter when the node is initialized; the odds of any two nodes having the same SenderID are very low.
  • Every set of associated NetMIDI nodes is labeled with a ‘Show Name’ (denoting a particular "show universe"; which is more-or-less equivalent to a session name). Each NetMIDI message is labeled with the CRC32 value of the associated Show Name. As long as no two Show Names produce the same CRC32 value, a very large number of shows (a.k.a. sessions) can coexist on the same network, given sufficient network bandwidth.
  • NetMIDI also provides a grouping mechanism. Each show universe (session) can define up to 32 groups. Every outgoing message can belong any desired combination of groups. Every NetMIDI receiver can listen for a single group or any combination of groups. Since the groups used by one show universe are totally distinct from the groups used in any other show universe, NetMIDI theoretically supports up to 32 * 2^32 different MIDI streams over a single shared network.