On Sun, 2006-07-23 at 16:27 -0700, lazzaro wrote: > On Jul 23, 2006, at 2:06 PM, Dave Robillard > <[EMAIL PROTECTED]> wrote: > > > I don't see it as much of a problem anyway. At least in all my use > > cases, there's realtime crucial data (eg what MIDI tends to do, > > controllers, notes, etc) and there's data that just needs to get there > > sanely. The nice thing about the realtime stuff is that lost messages > > don't really matter, all you care about is the most recent one anyway. > > > Well, consider a volume slider on a mixing console. > > One way to send its state is to sample its value and > send a packet every millisecond. In this case, your > "nice thing" is true -- the occasional burst of lost > or reordered packets will only cause brief "transient" > artifacts. The price paid for this "nice thing" is > sending 1000 packets per second, every second > of the performance. > > The more efficient way to send the slide state > is to only send packets when a human finger > moves the slider. In this case, your "nice thing" > is not true -- the slider might be moved by the > human once per minute, and if the packet coding > that move is lost, that lost packet matters for the > entire minute. > > RTP MIDI's recovery journal lets you safely use > this incremental update approach over a lossy > packet stream in an efficient way ... if > you need to send data over lossy networks > and that fits MIDI's semantics, and TCP's > head-of-line blocking latency is not acceptable, > I think RTP MIDI is the right protocol to use.
Yeah, the latest value being lost is the problem, if you wanted to really solve this problem you need to make sure that value actually gets there (which you could probably do in a similar/identical way that RTP MIDI does) You're missing the big overriding point here though: RTP Midi solves this transmission problem, yes - but it solves it for _MIDI_. Using incredibly disgusting SYSEX concoctions is simply not an acceptable substitute for what many people (in this myself and Loki) use OSC for. Noone who's already gone OSC would ever actually switch back to MIDI (especially custom sysex evil that throws interoperability completely out the window). Human readability and interoperability IS often important (eg using supercollider or pd or whatever to control things). It's like pitching a modem solution to a web server problem - I'm sure its a very nice solution for modems, but noone's making a web service that speaks the Hayes command set any time soon are they? ;) Anyway, as soon as you go sysex you lose the semantics and you have the same problem anyway - retransmission is the only possible solution if you know nothing about the data (it becomes application specific). RTP MIDI may be fantastic for what it does, but it's definitely no solution for OSC things like this - there's a reason you don't see things like Supercollider, Om/Ingen, etc using MIDI for client/server comms. Anyway, this problem could easily be solved in the app if the values are echoed back (as mine are) by just resending the latest value if it didn't make it. In practise - like most people - I don't actually control realtime audio stuff over lossy networks in situations where latency matters anyway, so I havn't bothered. It would be trivial to do though. -DR- (P.S. the latency incurred by using TCP on an even remotely decent network isn't nearly as bad as people tend to assume when this comes up) ^M ^M ATH0
