Roger Dannenberg did some real-time music work and compared UDP and TCP.
His findings may surprise you! See 4.2 UDP vs. TCP here:
https://www.cs.cmu.edu/~rbd/papers/icmc01aura.pdf tl;dr - he ended up going
with TCP with some tweaks to make it more timely.
Cheers!
mc
On Sun, Dec 2, 2018 at 12:47 PM Jordan Orelli <jordanore...@gmail.com>
wrote:
> I'm like ... 80% sure that there's no TCP-handling facilities built in,
> but I may be wrong here. If there is, I surely don't know about it.
>
> Can you tell us a little more about your use case?
>
> The design goals of TCP and ChucK are very different with respect to
> *time*. ChucK is designed around guarantees about time and timeliness.
> TCP is not designed around timeliness or latency in general: TCP is
> designed around guarantees about ordering (messages always appear in order)
> and delivery (messages are guaranteed to be delivered). Since every byte
> sent over a TCP socket has to be eventually acknowledged, and all bytes
> have to be processed in order, a stall in the network (a normal occurrence)
> could mean later messages being delayed, much like a traffic jam. It's not
> possible to have timing *guarantees *with TCP.
>
> I'm not sure how to find it in the source code, but maybe someone else
> here knows: does calling Std.system create a new shell process for each
> invocation? That would be a fairly inefficient way to go about things. Also
> since you're piping to another process, that's a new netcat process for
> each invocation (so it's either one or two processes per invocation), and a
> new TCP socket for every invocation. TCP is *especially slow *at *the
> very beginning of communication.*
>
> If I were in your shoes, I would probably write a separate program that
> acts as a server and serves an OSC-based protocol. This server would take
> your messages as OSC and translate them and then forward them to the
> intended recipient over just one TCP connection and continue to use that
> one connection the whole time. It may or may not respond to your ChucK
> program over OSC, depending on whether you want the ChucK program to get
> responses to its requests (probably not?).
>
>
> On Sat, Dec 1, 2018 at 1:25 PM mario buoninfante <
> mario.buoninfa...@gmail.com> wrote:
>
>> Hi,
>>
>>
>> It seems like accessing the shell and use "netcat" (on Unix) is a
>> possible solution. Quite an *exotic* workaround but better than nothing
>> I'd say.
>>
>> Something like that seems to work:
>>
>> *// run ChucK with "--caution-to-the-wind"*
>>
>> *"echo -ne '" => string prefix;*
>> *"' | netcat 127.0.0.1 3333 " => string suffix; // netcat <target ip>
>> <target port>*
>>
>> *while(true)*
>> *{*
>> * Math.random2(0,127) => int r;*
>> * prefix + Std.itoa(r) + suffix => string msg;*
>> * Std.system(msg);*
>>
>> * second => now;*
>> *}*
>>
>>
>> Please, let me know if anyone has a better solution.
>>
>>
>> Cheers,
>>
>> Mario
>> On 01/12/2018 18:04, mario buoninfante wrote:
>>
>> Hi,
>>
>>
>> I also tried opening a file in /dev/tcp/<target ip>/<target port>, but it
>> didn't work. I'm on Ubuntu 16.04. Any idea?
>>
>>
>> Cheers,
>>
>> Mario
>>
>>
>> On 30/11/2018 16:52, Mario Buoninfante wrote:
>>
>> Hi,
>>
>> Does anyone know if it's possible to use TCP instead of UDP in ChucK?
>>
>> Cheers,
>> Mario
>>
>>
>> --
>> Electronic Musician, Creative Coder, QA
>> Engineerhttps://vimeo.com/creativecodingsalernohttp://mbuoninfante.tumblr.com/https://github.com/mariobuoninfantehttps://bitbucket.org/mariobuoninfante/
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users@lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users@lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
