Hi Martijn, Comments inline:
martijn sipkema wrote: > > There are a small number of issues to fix, but the basic concept of > > having MIDI controllers broadcast data over a TCP/IP network and DMIDI > > hardware clients translate this data into raw MIDI (in as close to > > real-time as I can get) seems quite stable. > > > > The protocol is very simple, and does not seem to suffer from latency > > problems, on my network anyway. > > 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. > > 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). > > 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..... > > 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? > > --martijn
