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