On Sun, 2006-07-23 at 16:27 -0700, lazzaro wrote:
> On Jul 23, 2006, at 2:06 PM, Dave Robillard
> <drobilla@email-addr-hidden> 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
Received on Mon Jul 24 12:15:02 2006
This archive was generated by hypermail 2.1.8 : Mon Jul 24 2006 - 12:15:02 EEST