jaime.oliver2

does anybody know of an object or any other resource to send messages

as in a send/receive way from Max to Pd??

does anybody know of an object or any other resource to send messages
as in a send/receive way from Max to Pd??

communication-between-maxmsp-and-pd

besides OSC you have netsend / netreceive (external in Max)

Hello again and thanks for the answers. I am trying netsend/netreceive

and info seems to be passing ok from max to pd, but i get messages

Does this mean that the data is not passing continuously? that it is

> besides OSC you have netsend / netreceive (external in Max)

Hello again and thanks for the answers. I am trying netsend/netreceive
and info seems to be passing ok from max to pd, but i get messages
like these:

several times with variable msec values?
Does this mean that the data is not passing continuously? that it is
being blocked every once in a while??

On 1/6/07, julienbreval  wrote:
>
> besides OSC you have netsend / netreceive (external in Max)
>


> Hello again and thanks for the answers. I am trying netsend/netreceive

> and info seems to be passing ok from max to pd, but i get messages

> several times with variable msec values?

> Does this mean that the data is not passing continuously? that it is

Right. It just means that delivering the messages took 17 milliseconds. 

You get a waring for every attept to send that takes longer than 5 ms. 

However, the data gets through anyway, if not you'd get a warning 

I will probably update netsend ibn a few days because I think it uses 

the wrong time functio (systime_ms()) to figure out how long sending 

takes. I will change this to clock_getftime() because I have the slight 

feeling that ntsend is complaining far too often.

But until then, don't worry, 17 ms is not that bad at all. Just run a 

ping to your destinations IP, ping times are probably also several ms.

Jaime Oliver wrote:
> Hello again and thanks for the answers. I am trying netsend/netreceive
> and info seems to be passing ok from max to pd, but i get messages
> like these:
>
> netsend: warning: blocked 17 msec
>
> several times with variable msec values?
> Does this mean that the data is not passing continuously? that it is
> being blocked every once in a while??

Right. It just means that delivering the messages took 17 milliseconds. 
You get a waring for every attept to send that takes longer than 5 ms. 
However, the data gets through anyway, if not you'd get a warning 
telling you so.
I will probably update netsend ibn a few days because I think it uses 
the wrong time functio (systime_ms()) to figure out how long sending 
takes. I will change this to clock_getftime() because I have the slight 
feeling that ntsend is complaining far too often.

But until then, don't worry, 17 ms is not that bad at all. Just run a 
ping to your destinations IP, ping times are probably also several ms.

yes, 17ms is ok, but I have gotten messages up to 282ms. this

behaviour is quite erratic, sometimes it is 16-17 for a while and then

i am sending 18 streams of numbers (every 100ms) through netsend from

max to pd through localhost 3001. would it be advisable to use several

> > Hello again and thanks for the answers. I am trying netsend/netreceive

> > and info seems to be passing ok from max to pd, but i get messages

> > several times with variable msec values?

> > Does this mean that the data is not passing continuously? that it is

> > being blocked every once in a while??

> Right. It just means that delivering the messages took 17 milliseconds.

> You get a waring for every attept to send that takes longer than 5 ms.

> However, the data gets through anyway, if not you'd get a warning

> I will probably update netsend ibn a few days because I think it uses

> the wrong time functio (systime_ms()) to figure out how long sending

> takes. I will change this to clock_getftime() because I have the slight

> feeling that ntsend is complaining far too often.

> But until then, don't worry, 17 ms is not that bad at all. Just run a

> ping to your destinations IP, ping times are probably also several ms.

yes, 17ms is ok, but I have gotten messages up to 282ms. this
behaviour is quite erratic, sometimes it is 16-17 for a while and then
suddenly 85, 156, 256, etc.

i am sending 18 streams of numbers (every 100ms) through netsend from
max to pd through localhost 3001. would it be advisable to use several
ports??

On 1/6/07, Olaf Matthes  wrote:
> Jaime Oliver wrote:
> > Hello again and thanks for the answers. I am trying netsend/netreceive
> > and info seems to be passing ok from max to pd, but i get messages
> > like these:
> >
> > netsend: warning: blocked 17 msec
> >
> > several times with variable msec values?
> > Does this mean that the data is not passing continuously? that it is
> > being blocked every once in a while??
>
> Right. It just means that delivering the messages took 17 milliseconds.
> You get a waring for every attept to send that takes longer than 5 ms.
> However, the data gets through anyway, if not you'd get a warning
> telling you so.
> I will probably update netsend ibn a few days because I think it uses
> the wrong time functio (systime_ms()) to figure out how long sending
> takes. I will change this to clock_getftime() because I have the slight
> feeling that ntsend is complaining far too often.
>
> But until then, don't worry, 17 ms is not that bad at all. Just run a
> ping to your destinations IP, ping times are probably also several ms.
>
> Olaf
>


> yes, 17ms is ok, but I have gotten messages up to 282ms. this

> behaviour is quite erratic, sometimes it is 16-17 for a while and then

Uh, that's a lot for a localhost connection.

> i am sending 18 streams of numbers (every 100ms) through netsend from

> max to pd through localhost 3001. would it be advisable to use several

No, using one port is okay (or probably even better than using 2 or 

more). What does "18 streams of numbers (every 100ms)" mean exactly? 

And it seems you're running Max and Pd in parallel on the same machine? 

What's the CPU load with this setup? Pd is not threaded, so receiving 

the network data has to happen inbetween the audio processing. This 

could delay the reception of the numbers you send. If the Pd GUI starts 

to run jerky then receieing any network data will also block for short 

An option could be to use UDP instead of TCP, because then send doesn't 

have to wait for response from the receiver and just dumps the data into 

Jaime Oliver wrote:
> Dear Olaf,
>
> yes, 17ms is ok, but I have gotten messages up to 282ms. this
> behaviour is quite erratic, sometimes it is 16-17 for a while and then
> suddenly 85, 156, 256, etc.

> i am sending 18 streams of numbers (every 100ms) through netsend from
> max to pd through localhost 3001. would it be advisable to use several
> ports??

No, using one port is okay (or probably even better than using 2 or 
more). What does "18 streams of numbers (every 100ms)" mean exactly? 
Like every 100ms you send 18 integers?
And it seems you're running Max and Pd in parallel on the same machine? 
What's the CPU load with this setup? Pd is not threaded, so receiving 
the network data has to happen inbetween the audio processing. This 
could delay the reception of the numbers you send. If the Pd GUI starts 
to run jerky then receieing any network data will also block for short 
moments.
An option could be to use UDP instead of TCP, because then send doesn't 
have to wait for response from the receiver and just dumps the data into 
the network.

so if I have both programs runinng with a video patch in jitter to

track variables, then send the variables to pd (not doing any audio,

just testing the communication) and CPU goes approx from 45-55% and in

UDP it is much better with 35-45%, and mostly 17-34ms block, but still

with outbursts of 60%cpu and 200ms block.

i think i will have to use two machines...

Let me know if you update the objects and thank you very much for your help.

> > yes, 17ms is ok, but I have gotten messages up to 282ms. this

> > behaviour is quite erratic, sometimes it is 16-17 for a while and then

> Uh, that's a lot for a localhost connection.

> > i am sending 18 streams of numbers (every 100ms) through netsend from

> > max to pd through localhost 3001. would it be advisable to use several

> No, using one port is okay (or probably even better than using 2 or

> more). What does "18 streams of numbers (every 100ms)" mean exactly?

> And it seems you're running Max and Pd in parallel on the same machine?

> What's the CPU load with this setup? Pd is not threaded, so receiving

> the network data has to happen inbetween the audio processing. This

> could delay the reception of the numbers you send. If the Pd GUI starts

> to run jerky then receieing any network data will also block for short

> An option could be to use UDP instead of TCP, because then send doesn't

> have to wait for response from the receiver and just dumps the data into

so if I have both programs runinng with a video patch in jitter to
track variables, then send the variables to pd (not doing any audio,
just testing the communication) and CPU goes approx from 45-55% and in
UDP it is much better with 35-45%, and mostly 17-34ms block, but still
with outbursts of 60%cpu and 200ms block.

On 1/7/07, Olaf Matthes  wrote:
> Jaime Oliver wrote:
> > Dear Olaf,
> >
> > yes, 17ms is ok, but I have gotten messages up to 282ms. this
> > behaviour is quite erratic, sometimes it is 16-17 for a while and then
> > suddenly 85, 156, 256, etc.
>
> Uh, that's a lot for a localhost connection.
>
> > i am sending 18 streams of numbers (every 100ms) through netsend from
> > max to pd through localhost 3001. would it be advisable to use several
> > ports??
>
> No, using one port is okay (or probably even better than using 2 or
> more). What does "18 streams of numbers (every 100ms)" mean exactly?
> Like every 100ms you send 18 integers?
> And it seems you're running Max and Pd in parallel on the same machine?
> What's the CPU load with this setup? Pd is not threaded, so receiving
> the network data has to happen inbetween the audio processing. This
> could delay the reception of the numbers you send. If the Pd GUI starts
> to run jerky then receieing any network data will also block for short
> moments.
> An option could be to use UDP instead of TCP, because then send doesn't
> have to wait for response from the receiver and just dumps the data into
> the network.
>
> Olaf
>


communication between Max/MSP and Pd