Hi Jose,
Yes, that's a solution, you're right. But I was trying to do everything in
ChucK, also to avoid further bottlenecks due to conversions from UDP to TCP.
But I'll consider this option in case I can't find better solutions.
Cheers,
Mario
Sent from my Wiko ROBBYOn Dec 3, 2018 17:33, José de Abreu
<abreubace...@gmail.com> wrote:
>
> Just an idea, i know that you patch in puredata too Mario. How about making
> chuck send udp to puredata and making puredata send tcp from there? actually
> puredata could be any other software, just to make the bridge
>
> Em Seg, 3 de dez de 2018 13:24, Mario Buoninfante
> <mario.buoninfa...@gmail.com escreveu:
>>
>> Hi Jordan,
>>
>> Thanks for your reply.
>> I got your points and I think you're right about the different design goals.
>> In my case I simply need to talk with a piece of HW that 'speaks' TCP. But
>> the 'netcat' solution doesn't seem to be the best one, for all the reasons
>> you mentioned. Probably it's still the right direction, but it needs to be
>> refined for sure.
>> If I simple open a port using Std.system(), without immediately closing it,
>> that'll take over the shell and my ChucK script won't proceed (the shell
>> waits for some input).
>> The idea of having 2 shells opened, and make 2 different scripts talking to
>> each other, could be a solution and I want to give it a try. That said,
>> having to convert from OSC/UDP, to TCP could further affect the
>> performances. Anyway, I'll have a look and share with the mailing list in
>> case I end up with something useful.
>>
>> Cheers,
>> Mario
>>
>> On Sun, 2 Dec 2018 at 20:47, 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 Engineer
>>>>
>>>> https://vimeo.com/creativecodingsalerno
>>>>
>>>> http://mbuoninfante.tumblr.com/
>>>>
>>>> https://github.com/mariobuoninfante
>>>>
>>>> https://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
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
