Hi Martijn, The max. packet size at the moment is 256 bytes. This is because I'm unable to read the UDP packet size directly and strlen would barf at the first 0x00 value, so I use the fourth node id byte as packet size. This is top of the list to fix!
The theoretical max for UDP packet size is a shade under 64k, but few platforms support this limit, some support 32k some only 8k. So the most portable size is just under 8k, although your system may handle more. DMIDI is only a packetizing protocol, data is wrapped-up with a node id , then sent. On the receiving end the raw midi data is sent to the device serially. As you mention, allowing the hardware to detect bad data is far preferable than trying to emulate this in software. So you can have a DMIDI packet containing note-on on chan 1, pan on chan 2 and so on. DMIDI routes this out to the midi device as raw MIDI data, then all the normal functionality, quirks and failures of MIDI take over. To MIDI this data appears on the wire as if it's come from any other MIDI device. This also affects interleaving and the whole way that nodes interrelate. If you have two MIDI sequencers sending data to one sampler, you may or may not encounter problems. Same thing with DMIDI, if you can do this with adverse effects using stock MIDI kit then you'll have the same problems. Node id's are really an extension of midi chan's. You can call it a cable number as well if you wish :) if you have 5 nodes each with a MIDI device on chan 10 how do you say 'kick drum1 on the second Korg on the right, not the Roland on the bottom' . I used sysex manufacturers ID as the basis for node ID's as this seemed a reasonable thing to do. The initial spec, specifies that the values in the node ID section should be hex, but they could be alphanumeric, so instead of node 0x1122ffee the node could be 909a or krg1. Suggestions welcome on the best approach. DMIDI then broadcasts the packed over the subnet and clients should then examine the packet, check to see if the node ID is theirs (or the first byte starts with 0xff) and then pass the remaining data to the MIDI hardware, or not as the case may be. The DMIDI hardware client can receive interleaved data without problem, but the existing MIDI problems will still be present. Data to chan 1 on node 0x11223344 shouldn't affect data to chan 2 on the same node. Interleaving sysex data with normal data isn't good. DMIDI doesn't impose any restrictions on this problem over MIDI. If you are in the middle of sending sysex from whatever device (say chan 1) and you send note info to chan 1, you will get problems. However if the sysex is contained within one DMIDI packet it's going to be dispatched to the device in fairly rapid order and this will minimize the problem (but not solve it). But DMIDI shouldn't cause problems if half way through receiving sysex on chan one it switches to sending data to chan 2 then back. Technically the MIDI device doesn't know anything about who/what has supplied the data and shouldn't care if it's switched for a moment (I presume internally the hardware buffers the sysex until it receives an EOX or a value greater than 0x7f). On a private network, not a network sending buckets of NFS/Samba/ARP/HTTP packets, and with half decent NIC's and cable you should have latencies less than 1ms. In work I don't cut-back on hub's, switches or cable I buy the best. I've seen and heard too many horror stories concering large scale systems being held together with $20 hubs and taped together patch cables. Would you cable your studio with bell-wire, thought not! If you are going to use a network for anything resembling real-time, or high-volume, applications you do not buy cheap. I initially looked at RTP for exactly the reasons you mention, but I prototyped things using plain UDP just to see what worked out. So far RTP looks like overkill when you look at the cost/benefit ratio. I've only managed to lose packets when pushing things hard. But from what I understand of RTP the same thing would/could happen if the protocols are switched. The timestamps are used for stream reassembly or deciding if the datagrams are too late and should be dropped. There is a point where you cannot compensate for lousy networks. However, if RTP is the way to go to provide an extra level of 'protection' against delays then this is the way it goes. This is no. 2 on the list :) DMIDI packet saturation will have the same effect as saturating a MIDI device, packets will be dropped silently, but i've been able to do this with my Atari ST/Cubase and a number of Pro. MIDI devices for ages :) Phil martijn sipkema wrote: > > > why did you choose to have an udp packet per midi message and not > > > have one midi byte per packet? > > > > Both are allowed. The example dmidid client receives bundled MIDI data, > but > > transmits single packets per midi byte. > > OK. Should there be a maximum size for a message? it is > 256 right now, but you intent to remove that? > > Sending one byte per UDP packet has the advantage that > if one packets is losst, e.g. a byte from a note on message, > the receiver will be able to at least know that an error occured. > > How is interleaving handled. Is the transmitters IP used to seperate > different streams? Can one host send multiple streams to one 'node' > on another host? > > Why did you choose for the node number in its current form? Why > not just a 'cable' number? > > > > how will sysex be handled? > > > > Either as one DMIDI packet, or as a stream of single packets. To the > > receiving MIDI device there shouldn't be any difference. I'll check > tomorrow > > if this is a problem (so far only tested with note and control data). > > Again the issue of interleaving. sysex may only be interleaved by MIDI > realtime > status bytes. Any other status will cancel/stop the sysex transmission. > > > > there is nothing in the protocol to handle losing packets or to prevent > it. > > > > > > a constant delay for the midi stream is often acceptable and the > protocol > > > might use this for handling loss of packets. perhaps RTP could be used? > > > sending a packet a couple of times can reduce packet loss. > > > > > I'm looking at either TCP or RTP as replacement protocols if loss becomes > an > > issue. I'd only recommend DMIDI on a private network, not a busy public > one. > > Right now consider your network as a musician, bad network..... > > TCP might not be the best solution, but using RTP should be investigated > IMHO. > I'm not sure, but doesn't RTP have timestamps? The current DMIDI protocol > doesn't have timestamps and as such doesn't allow for sending packets > slightly > ahead to reduce jitter and have a acceptable (constant) delay, e.g. 2ms > (less or > more depending on the network). > > > > the protocol probably should also have a requirement to the data rate, > > > i.e. it should not allow a higher data rate than MIDI 1.0 > > > > Good point. I saw it as a good sign when I saw RX buffer errors on my > > Promix, it meant I was sending data *fast* enough! I've not seen anything > > else filter for this, do you regard this as a big problem? > > > > I'm not sure, is there a way for the receiver to indicate it is not able to > handle > the incoming flow if UDP packets (flow control) or will they just get losst > eventually? > > --martijn
