Le 2021-05-02 à 15 h 37, Winfried Ritsch a écrit :
> Please disagree if you can reference:
> - OSC 1.0 ist not only UPD
The liblo library and tools works with TCP (also UDP and Unix sockets):
http://liblo.sourceforge.net/
> - OSC was not a intended to replace MIDI,
> but to use it in multidimensional musical parameter transmission, like the
> 3D-Postion of a violin bow....
> - OSC predecessor was ZIPI not MIDI
>
> see https://web.archive.org/web/20070609125702/http://www.cnmat.berkeley.edu/
> ZIPI/
> (see: what next ?)
The complete CMJ article :
https://cnmat.berkeley.edu/sites/default/files/attachments/1994_the_ZIPI_music_parameter_description_language.pdf
It's a bit like MIDI, where a lot is defined; despite being a domain
specific protocol, MIDI is often used for non-musical use cases with
note on/off or pitch bend messages... So when possible, using OSC can
make a lot more sense.
> BTW.: There has been an interesting paper with critics to OSC from
> Computermusic scientists:
> - https://www.cs.cmu.edu/~rbd/papers/o2-web.pdf
It's true that OSC does not have Zeroconf capabilities (like the popular
NDI protocol for sharing video streams between applications); OSCQuery
tries to fix that (and other issues):
https://github.com/Vidvox/OSCQueryProposal
As for OSC timestamps, it's possible to add them in the OSC messages, as
an application specific feature, but it would add more latency. To avoid
jitter, one possible hack would be to use lossy audio streams to
transport control data (but it could be a bad idea).
Marc
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon May 3 04:15:02 2021
This archive was generated by hypermail 2.1.8 : Mon May 03 2021 - 04:15:02 EEST