[PD] problem using [udpsend] from iemnet (or mrpeach) in a sub-process (with [pd~])

[Bernardo Barros]

Maybe that is a limitation of the PD "control rate" cords. You only
get "audio rate" messages between audio boxes.

2010/8/20 Jack <jack at rybn.org>:
> Le vendredi 20 août 2010 à 11:58 -0300, Bernardo Barros a écrit :
>> sorry: 44100 (or 48000 or 96000)
>>
>> 2010/8/20 Bernardo Barros <bernardobarros2 at gmail.com>:
>> > maybe as audio signal through JACK? That is the fastest way I'm aware.
>> > That would be 441000 values per second per channel -1.0/+1.0, then you
>> > had to rescale again.
> Yep, i used to use JACK. But always slow here ;)
> Thanx anyway.
> ++
>
> Jack
>
>
>> >
>> > 2010/8/20 Jack <jack at rybn.org>:
>> >> Hello Mathieu,
>> >>
>> >> I have already do that with [packOSC]/[unpackOSC] and
>> >> [udpsend]/[udpreceive], it is slow too.
>> >> I need to send 20000 lists of 3 floats (id, pos x, pos y) each frame (50
>> >> fps) from one process to other.
>> >> Thanx.
>> >> ++
>> >>
>> >> Jack
>> >>
>> >>
>> >> Le vendredi 20 août 2010 à 10:20 -0400, Mathieu Bouchard a écrit :
>> >>> On Fri, 20 Aug 2010, Jack wrote:
>> >>>
>> >>> > Is there another method to accelerate this transfert between GEM and MSD
>> >>> > using [pd~] and [stdout] ?
>> >>>
>> >>> Can you try communicating with OSC instead, and see whether it's faster ?
>> >>> It does lesser amounts of encoding and decoding for floats, than what
>> >>> [netsend]/[netreceive]/[stdout]/[pd~] need. How many floats do you need to
>> >>> send from one process to the other, per second ?
>> >>>
>> >>>   _ _ __ ___ _____ ________ _____________ _____________________ ...
>> >>> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Pd-list at iem.at mailing list
>> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>> >>
>> >
>
>
>