Am Montag, 3. Mai 2021, 11:48:07 CEST schrieb Fons Adriaensen:
On Sun, May 02, 2021 at 09:37:40PM +0200, Winfried
Ritsch wrote:
Please disagree if you can reference:
- OSC 1.0 ist not only UPD
In theory this is true, but if you use any transport that does not
provide message boundaries, you need close integration of the data
receiving code and the actual parsing of the OSC message. This is
because you don't know where in a stream of bytes for a message
ends until you have at least parsed the path and the format string.
So you can't just 'wait for a message' without interpreting it and
then only when it is complete pass it to a decoder.
true
If the transport is just a stream of bytes, you
*could* wait
until no more data is received for some time and assume that the
message is then complete, and pass it to a decoder. This will of
course introduce delay, and it could easily fail.
Now UDP is the only common transport that *does* provide message
boundaries, so probably that's why it is said that you need UDP.
On the other side, with the type tags, you know when a message is complete if
you wait for number of bytes or the the type ends(, if no bytes got lost...)
The problem of UDP: UDP applications must be willing to accept some packet
loss or this has to be handled by the protocol implemented with OSC. and/or it
should be a "stateless" protocol.
So if package loss is a problem, think of a mute action TCP/IP is more easy to
handle, since we know when a connection is lost.
So maybe its better to do stream parsing and a stream protocol than UDP and
some handshake or failsave protocol, but of course this depends on the use
case, so on a sound system critical mixer I prefer TCP/IP.
- OSC was not
a intended to replace MIDI,
True.
- OSC predecessor was ZIPI not MIDI
True, sort of.
Ciao,
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch(a)iem.at -
http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171