Cycling 74 » Topic: Are send~ and receive~ really that expensive?

Are send~ and receive~ really that expensive?

Justin Yang — Wed, 01 Feb 2006 23:28:51 +0000

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

Re: Are send~ and receive~ really that expensive?

mzed — Thu, 02 Feb 2006 00:13:20 +0000

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).

mzed

Re: Are send~ and receive~ really that expensive?

Peter Castine — Thu, 02 Feb 2006 09:37:23 +0000

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

0.075% is not a lot of extra CPU.

200 of ‘em *is* a lot.

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

– P.

Re: Are send~ and receive~ really that expensive?

John Nowak — Thu, 02 Feb 2006 13:17:51 +0000

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).

- John

Re: Are send~ and receive~ really that expensive?

Jean-Francois Charles — Thu, 02 Feb 2006 17:35:02 +0000

Re: Are send~ and receive~ really that expensive?

Roman Thilenius — Thu, 02 Feb 2006 18:55:35 +0000

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.

-receive me 110 times

Re: Are send~ and receive~ really that expensive?

Roman Thilenius — Thu, 02 Feb 2006 19:25:57 +0000

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.

-funny 110

Re: Are send~ and receive~ really that expensive?

Mark Pauley — Thu, 02 Feb 2006 21:27:15 +0000

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.

_Mark

Re: Are send~ and receive~ really that expensive?

projects — Fri, 03 Feb 2006 08:18:56 +0000

> 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.

Ben

Re: Are send~ and receive~ really that expensive?

Salvator — Fri, 03 Feb 2006 09:45:43 +0000

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.

Salvator

Re: Are send~ and receive~ really that expensive?

Peter Castine — Fri, 03 Feb 2006 10:03:45 +0000

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.

– Peter (adding to the noise, but noise is my business, isn’t it?

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

Re: Are send~ and receive~ really that expensive?

noid — Fri, 03 Feb 2006 11:49:43 +0000

maybe try the “send” – “receive” without “~”
that could solve your problem
also you don’t have a delay then (one signal vector size)

best
n

Re: Are send~ and receive~ really that expensive?

Peter Castine — Fri, 03 Feb 2006 12:04:15 +0000

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.

– P

Re: Are send~ and receive~ really that expensive?

Peter Castine — Fri, 03 Feb 2006 12:08:15 +0000

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.

Plain-vanilla send/receive (no tildes).

Re: Are send~ and receive~ really that expensive?

f.e — Fri, 03 Feb 2006 12:15:51 +0000

and for sending signals ?

Re: Are send~ and receive~ really that expensive?

Thijs Koerselman — Fri, 03 Feb 2006 12:49:25 +0000

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.

T-

Re: Are send~ and receive~ really that expensive?

Salvator — Fri, 03 Feb 2006 12:54:02 +0000

Works great !
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 ?

Thanks,

Salvator

Re: Are send~ and receive~ really that expensive?

Peter Castine — Fri, 03 Feb 2006 13:49:14 +0000

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.

Here, try it:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 258 89 67 196617 startwindow;
#P user ezdac~ 258 111 302 144 0;
#P user scope~ 62 185 192 315 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 62 161 94 196617 r look-ma-no-tilde;
#P newex 62 92 94 196617 s look-ma-no-tilde;
#P newex 62 65 49 196617 cycle~ 1;
#P connect 5 0 4 0;
#P connect 2 0 3 0;
#P connect 0 0 1 0;
#P window clipboard copycount 6;

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~.

– Peter

Re: Are send~ and receive~ really that expensive?

Thijs Koerselman — Fri, 03 Feb 2006 15:14:28 +0000

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? :-)

T-

Re: Are send~ and receive~ really that expensive?

Dan Nigrin — Fri, 03 Feb 2006 15:37:59 +0000

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

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

http://www.jackosx.com

Re: Are send~ and receive~ really that expensive?

nathan wolek — Fri, 03 Feb 2006 15:53:02 +0000

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

Re: Are send~ and receive~ really that expensive?

Thijs Koerselman — Fri, 03 Feb 2006 16:15:50 +0000

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.

T-

Re: Are send~ and receive~ really that expensive?

lexein — Fri, 03 Feb 2006 16:53:34 +0000

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.

Re: Are send~ and receive~ really that expensive?

Roman Thilenius — Fri, 03 Feb 2006 17:05:22 +0000

Re: Are send~ and receive~ really that expensive?

Roman Thilenius — Fri, 03 Feb 2006 17:24:59 +0000

> 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.