Justin Yang

I have made a patch that uses about 200 send~ and receive~ objects. 

When these are present my CPU consumption jumps to about 15%. I 

thought Send~ and receive~ were just like connecting with a audio 

signal patch cord and did not tax the CPU. Do send/receive~ tax the 

Hi Max Community,
I have made a patch that uses about 200 send~ and receive~ objects.  
When these are present my CPU consumption jumps to about 15%.  I 
thought Send~ and receive~ were just like connecting with a audio 
signal patch cord and did not tax the CPU.  Do send/receive~ tax the 
CPU or is something else wrong.
Thanks in advance,
Justin Yang


are-send-and-receive-really-that-expensive

Quote: Justin Yang wrote on Wed, 01 February 2006 15:28

>Do send/receive~ tax the CPU or is something else wrong.

Send~ and receive~ make a copy of the signal. (send and receive don't).

Quote: Justin Yang wrote on Wed, 01 February 2006 15:28
>Do send/receive~ tax the CPU or is something else wrong.

15%/200 -> approx 0.075% per send~/receive~ pair.

As Michael pointed out, plain-vanilla s/r (or patch cords) will be 

| Litter Power & Litter Bundle for Jitter

pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building

http://www.dspaudio.com/software/software.html

As Michael pointed out, plain-vanilla s/r (or patch cords) will be 
cheaper.

Is there any functional/technical reason why they'd use any 

additional CPU power? I assumed they were just language semantics, 

syntactic sugar if you will, and that they'd be incorporated into the 

DSP chain as if they were standard connections after the chain was 

compiled. If they do not introduce any different functionality than 

standard patch cables, why not do it this way? The interface would 

behave identically regardless of behind-the-scenes activity. At the 

very least, this should be possible if the send~/receive~ pairs exist 

within the same patch. Correct me if I'm wrong (I don't get to see 

Is there any functional/technical reason why they'd use any  
additional CPU power? I assumed they were just language semantics,  
syntactic sugar if you will, and that they'd be incorporated into the  
DSP chain as if they were standard connections after the chain was  
compiled. If they do not introduce any different functionality than  
standard patch cables, why not do it this way? The interface would  
behave identically regardless of behind-the-scenes activity. At the  
very least, this should be possible if the send~/receive~ pairs exist  
within the same patch. Correct me if I'm wrong (I don't get to see  
the source code).

normally send~ does not need that much. but i suppose

the sends are also connected to something else, or

you use several send~ all with the same name.

250 different [receive~] should not need more than 3% on

a G5, but250 copies of [receive~ foo] would need much more.

normally send~ does not need that much. but i suppose
the sends are also connected to something else, or
you use several send~ all with the same name.

250 different [receive~] should not need more than 3% on
a G5, but250 copies of [receive~ foo] would need much more.

compare that to the CPU usage of objects like cycle~ 

or sfv~ - which actually do something - and you will 

not a lot of CPU? 
compare that to the CPU usage of objects like cycle~ 
or sfv~ - which actually do something - and you will 
understand why he asked.

It might have to do with symbol lookup each DSP interrupt as well.

send~ and receive~ are global, across patches even. Even then, the 

symbol-lookup is probably hash-based, so it shouldn't be an issue.

Maybe there is some sort of synchronization that has to be done with 

these objects each DSP interrupt that is pricey. This could be the 

case if semantically you can expect all receive~'s on a given symbol 

to happen before send~'s. And what are the semantics of multiple 

send~'s to the same symbol? Does the symbol get mixed like the 

regular DSP chain? Perhaps a degenerate case of the send~ receive~ 

semantics would allow for more performance.

I've seen a bunch of complaints about send~ and receive~ overhead, 

maybe it's time one of us did some snooping to see just why they cause 

It might have to do with symbol lookup each DSP interrupt as well.
send~ and receive~ are global, across patches even.  Even then, the  
symbol-lookup is probably hash-based, so it shouldn't be an issue.

Maybe there is some sort of synchronization that has to be done with  
these objects each DSP interrupt that is pricey.  This could be the  
case if semantically you can expect all receive~'s on a given symbol  
to happen before send~'s.  And what are the semantics of multiple  
send~'s to the same symbol?  Does the symbol get mixed like the  
regular DSP chain?  Perhaps a degenerate case of the send~ receive~  
semantics would allow for more performance.

I've seen a bunch of complaints about send~ and receive~ overhead,  
maybe it's time one of us did some snooping to see just why they cause  
this amount of overhead.

> If they do not introduce any different functionality than

> standard patch cables, why not do it this way?

There IS additional functionality. Load up the help file and you'll

see that the destination of a send~ can be changed with a set message.

> If they do not introduce any different functionality than
> standard patch cables, why not do it this way?

There IS additional functionality.  Load up the help file and you'll
see that the destination of a send~ can be changed with a set message.

I stopped using those send~ and receive~ because of this slight CPU overhead and went back with busy patch, full of chords...

For sure I would be interested with a new externals that use no more CPU than the straight chord (s~ & r~ ?), even if there is no "set" message allowed.

On around Feb 3, 2006, at 9:18, Ben Nevile, quoting I don't know who, 

>> If they do not introduce any different functionality than

>> standard patch cables, why not do it this way?

> There IS additional functionality. Load up the help file and you'll

> see that the destination of a send~ can be changed with a set message.

They do even more than that, as has been pointed out on the list dozens 

of times, and only about three messages earlier in this very thread.

If people would read as much as they write, there would be a double 

win: they would know more and there would be a better S/N on the list.

-- Peter (adding to the noise, but noise is my business, isn't it?

Cf. the first link below if you don't get it.)

On around Feb 3, 2006, at 9:18, Ben Nevile, quoting I don't know who, 
said something like:
>> If they do not introduce any different functionality than
>> standard patch cables, why not do it this way?
>
> There IS additional functionality.  Load up the help file and you'll
> see that the destination of a send~ can be changed with a set message.

They do even more than that, as has been pointed out on the list dozens 
of times, and only about three messages earlier in this very thread.

If people would read as much as they write, there would be a double 
win: they would know more and there would be a better S/N on the list.

maybe try the "send" - "receive" without "~"

also you don't have a delay then (one signal vector size)

maybe try the "send" - "receive" without "~"
that could solve your problem
also you don't have a delay then (one signal vector size)

On around Feb 2, 2006, at 20:25, Roman Thilenius said something like:

> compare that to the CPU usage of objects like cycle~

As has been pointed out innumerable times on this list, send~/receive~ 

Cycle~ is interpolated table-lookup. Send~/receive~ copy/buffer data. 

Both operations are simple. I would expect both to be roughly in the 

same ballpark, CPU-wise. Experience shows that send~/receive~ are 

actually a bit heavier on the CPU than cycle~ objects. But not so much 

so that I would lose sleep over wondering why. Assuming MSP uses the 

same algorithms as the equivalent Pd objects, someone suffering from 

insomnia could suss out the Pd source to discover the reason.

On around Feb 2, 2006, at 20:25, Roman Thilenius said something like:
>> 0.075% is not a lot of extra CPU.
>
> not a lot of CPU?
> compare that to the CPU usage of objects like cycle~
> or sfv~ - which actually do something

As has been pointed out innumerable times on this list, send~/receive~ 
most certainly "do something".

Cycle~ is interpolated table-lookup. Send~/receive~ copy/buffer data. 
Both operations are simple. I would expect both to be roughly in the 
same ballpark, CPU-wise. Experience shows that send~/receive~ are 
actually a bit heavier on the CPU than cycle~ objects. But not so much 
so that I would lose sleep over wondering why. Assuming MSP uses the 
same algorithms as the equivalent Pd objects, someone suffering from 
insomnia could suss out the Pd source to discover the reason.

On around Feb 3, 2006, at 10:45, Salvator said something like:

> For sure I would be interested with a new externals that use no more 

> CPU than the straight chord (s~ & r~ ?), even if there is no "set" 

On around Feb 3, 2006, at 10:45, Salvator said something like:
> For sure I would be interested with a new externals that use no more 
> CPU than the straight chord (s~ & r~ ?), even if there is no "set" 
> message allowed.

I didn't know about this, but apparently s/r can also be used for

signals! Shouldn't that be in the docs somewhere? (I can't find it) I think

it's pretty important, considering that you don't have the vector delay and

I didn't know about this, but apparently s/r can also be used for
signals! Shouldn't that be in the docs somewhere? (I can't find it)  I think
it's pretty important, considering that you don't have the vector delay and
also less cpu load this way.

I didn't knew that one and it's not in the MSP manual !

Is there others MAX objects (no tildes) that can be used for MSP signal or is this the sole exeption ?

Works great ! 
I didn't knew that one and it's not in the MSP manual ! 

On around Feb 3, 2006, at 13:15, f.e said something like:

Yes, that's the point: plain-vanilla s/r *do* work with MSP objects. 

Not only that, they're the objects that make signal connections with 

Don't be disconcerted by the fact that some of the patch cords aren't 

Nota bene: s/r will not help you with feedback loops in MSP. If you 

have a MSP patch with a feedback loop, you will have to use 

On around Feb 3, 2006, at 13:15, f.e said something like:
> and for sending signals ?

Yes, that's the point: plain-vanilla s/r *do* work with MSP objects. 
Not only that, they're the objects that make signal connections with 
effectively no performance overhead.

Don't be disconcerted by the fact that some of the patch cords aren't 
striped. That's cosmetic.

Nota bene: s/r will not help you with feedback loops in MSP. If you 
have a MSP patch with a feedback loop, you will have to use 
send~/receive~.

strange thing to find out about this even after years of programming in max,

and I'm not the only one that's surprised. It's a well kept secret...but

strange thing to find out about this even after years of programming in max,
and I'm not the only one that's surprised. It's a well kept secret...but
why? :-)

The concept of sending audio through s/r *is* documented - MSP 

"You can transmit MSP signals remotely with send and receive, too, 

but the patch cord(s) coming out of receive will not have the 

yellow-and-black striped appearance of the signal network (because a 

receive object doesn't know in advance what kind of message it will 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

The concept of sending audio through  s/r *is* documented - MSP 
Tutorial 4, page 74, second paragraph:

"You can transmit MSP signals remotely with send and receive, too, 
but the patch cord(s) coming out of receive will not have the 
yellow-and-black striped appearance of the signal network (because a 
receive object doesn't know in advance what kind of message it will 
receive)."

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


On Feb 3, 2006, at 10:14 AM, Thijs Koerselman wrote:

I seem to recall the thread announcing this discovery a few years 

back and that even David Z was surprise to hear that this works. I 

guess the best way to put is that this is an "unintended feature". 

The lack of documentation reflects this designation.

On Feb 3, 2006, at 10:14 AM, Thijs Koerselman wrote:
> It's a well kept secret...but why? :-)

I seem to recall the thread announcing this discovery a few years  
back and that even David Z was surprise to hear that this works.  I  
guess the best way to put is that this is an "unintended feature".   
The lack of documentation reflects this designation.

-----
Nathan Wolek
nw@nathanwolek.com
http://www.nathanwolek.com


> The concept of sending audio through s/r *is* documented - MSP Tutorial

That's still kind of undocumented imo. It needs to be in the reference

manual, because people don't expect to find this information in the

On 2/3/06, Dan Nigrin  wrote:
>
> The concept of sending audio through  s/r *is* documented - MSP Tutorial
> 4, page 74, second paragraph:
>

That's still kind of undocumented imo. It needs to be in the reference
manual, because people don't expect to find this information in the
tutorials.

One theory of technical writing states that each piece

of information should be stated once and only once. 

The (single) grand index should then cover _all_

documentation which is provided as a set. 

One theory of technical writing states that each piece
of information should be stated once and only once. 
The (single) grand index should then cover _all_
documentation which is provided as a set.  
Nothing would be left "undocumented"
For example 
 send/recieve, Ref 52
   audio, Tut 44
   control, Ref 52
or whatever.


> That's still kind of undocumented imo. It needs to be in the reference

> manual, because people don't expect to find this information in the

the reference says "input: anything, mouse"

the alt-control-menu also does not say "signal".

i found out that you can do it back in the days simply 

because i do not read manuals or helpfiles that often,

after years i still do not know by heart what objects

allow me to use signal input for which inlets, but who 

> That's still kind of undocumented imo. It needs to be in the reference
> manual, because people don't expect to find this information in the
> tutorials.
>
> T-

the reference says "input: anything, mouse"
the helpfile uses messages and ints.
the alt-control-menu also does not say "signal".

i found out that you can do it back in the days simply 
because i do not read manuals or helpfiles that often,
after years i still do not know by heart what objects
allow me to use signal input for which inlets, but who 
cares, i just try it out when i need it.


> i would choose that we can switch s and r connections like you

> cando it with send~ and recieve~. it is great that they work that

> way and the only reason why i would use them, and i would wish i 

> had dynamic sends for messages and numbers.

try [forward]. It takes a couple extra ms to type(depending on your 

typing prowess), but it does exactly what you are talking about.

> i would choose that we can switch s and r connections like you
> cando it with send~ and recieve~. it is great that they work that
> way and the only reason why i would use them, and i would wish i 
> had dynamic sends for messages and numbers.

try [forward].  It takes a couple extra ms to type(depending on your 
typing prowess), but it does exactly what you are talking about.

On Feb 3, 2006, at 3:18 AM, Ben Nevile wrote:

You're right -- I realized that this morning when sitting down to 

>> If they do not introduce any different functionality than
>> standard patch cables, why not do it this way?
>
>
> There IS additional functionality.  Load up the help file and you'll
> see that the destination of a send~ can be changed with a set message.

You're right -- I realized that this morning when sitting down to  
check my email.

These seems relevant to the difference between send~ and send.

> try [forward]. It takes a couple extra ms to type(depending on your 

> typing prowess), but it does exactly what you are talking about.

> try [forward].  It takes a couple extra ms to type(depending on your 
> typing prowess), but it does exactly what you are talking about.
>
> ;)
>
> Andrew B.

It adds some game modes to the original [forward] concept, take a look...

or you could try this object : fe.fwd 
 (.js for now, but 
on its way to .mxe)
It adds some game modes to the original [forward] concept, take a look...

On around Feb 3, 2006, at 18:24, Roman Thilenius said something like:

> the reference says "input: anything, mouse"

> the alt-control-menu also does not say "signal".

If it says "anything", it doesn't need to say anything else. Reading 

what the reference says about the "anything" message really says all 

Reading the list is also a great resource. That s/r work with signals 

has been discussed many, many times in the past. Justin may not have 

been on the list long enough to have seen this before, but you have.

On around Feb 3, 2006, at 18:24, Roman Thilenius said something like:
> the reference says "input: anything, mouse"

> the helpfile uses messages and ints.
> the alt-control-menu also does not say "signal".

If it says "anything", it doesn't need to say anything else. Reading 
what the reference says about the "anything" message really says all 
you need to know.

Reading the list is also a great resource. That s/r work with signals 
has been discussed many, many times in the past. Justin may not have 
been on the list long enough to have seen this before, but you have.

so there is reason for more noise for the two of us.

"you can connect int, float, messages, symbols, 

lists and audio or videosignals to at least one 

which does not mean that this object is also able 

to _take audio signals and _do something with them.

try connecting a signal cord to [next], [onebang], or

[print], which all allow "anything" to be connected

and you will see why in 110?s opinion the descripton 

of the [send] object is _wrong documented in the 

reference book; because it can do soemthing with 

[send] would have to be mentioned in the MSP reference

if you ask me, just like [out] and [out~] are.

but (anything) is not anything! 
so there is reason for more noise for the two of us.

"you can connect int, float, messages, symbols, 
lists and audio or videosignals to at least one 
of this objects inlets".

which does not mean that this object is also able 
to _take audio signals and _do something with them.

try connecting a signal cord to [next], [onebang], or
[print], which all allow "anything" to be connected
and you will see why in 110?s opinion the descripton 
of the [send] object is _wrong documented in the 
reference book; because it can do soemthing with 
signals.

[send] would have to be mentioned in the MSP reference
if you ask me, just like [out] and [out~] are.

Are send~ and receive~ really that expensive?