Are send~ and receive~ really that expensive?

Justin Yang

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

mzed

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

Peter Castine

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.

John Nowak

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

Roman Thilenius

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

Roman Thilenius

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

Mark Pauley

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

projects

> 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

Salvator

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

Peter Castine

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

noid

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

Peter Castine

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

Peter Castine

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

f.e

and for sending signals ?

Thijs Koerselman

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-

Salvator

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

Peter Castine

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:

Max Patch

Copy patch and select New From Clipboard in Max.

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

Thijs Koerselman

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-

Dan Nigrin

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

nathan wolek

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

Thijs Koerselman

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-

lexein

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.

Roman Thilenius

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

Andrew Benson

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

;)

Andrew B.

Andrew Benson

To clarify:

Max Patch

Copy patch and select New From Clipboard in Max.

--
AB

John Nowak

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

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

- John

mzed

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

Max Patch

Copy patch and select New From Clipboard in Max.

Roman Thilenius

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

hehee ... see i know nothing about max!

f.e

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

f.e

Emmanuel Jourdan

Peter Castine

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

Anything.

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

-- P.

Roman Thilenius

>
>Anything.
>

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

"anything" stands for:

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

curious for you next argument,

-110 *transmediale*

Stefan Tiedje

Max Patch

Copy patch and select New From Clipboard in Max.

Andrew Benson wrote:
> To clarify:
>
>

But as Andrews example shows, settable send and forward are not really
usable in MSP land, because it needs a restart of the MSP chain to make
it work!

If you need to set destinations or want to feedback audio, use send~ and
receive~, for anything else s and r, are faster. (In DSP and in time, as
send~, receive~ introduce one vector of delay.)

Stefan

[][] [][][] [][] [][][] [][] [][][] [][] [][][]
[][][][][][][][][][][][][][][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

-------------------------x---
--_____-----------|----------
--(_|_ ----|-----|-----()---
-- _|_)----|-----()----------
----------()------------x----

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72

projects

> > (In DSP and in time, as send~, receive~ introduce one vector of
> > delay.)
>
> Not true. The example bellow demonstrates send~/reveive~ pairs can
> have no extra latency. Can somebody explain that? I'm really confuse...

send~ and receive~ only introduce a vector of latency when they are
used to create a feedback loop.

Ben

Roman Thilenius

jasch

what about when send~ing audio between pluggos,
what's the latency there?
(let's say in a host like cubase or logic, when using plugsend~ or send~to make
a sidechain)

/*j

> send~ and receive~ only introduce a vector of latency when they are
> used to create a feedback loop.

magellan

this is great news !
I'm really glad we have a forum for this.

so send and receive is less cpu and less latencies ???
but we can't change the desitination except by through typing them with arguments, right ??

Roman Thilenius

plugsend~ itself does not produce latency (afaik),
so it should be 0 samples in any host which has
full PDC between any channels.
(_between channels - not for plug-ins)

there are some oddities in LAP .. and you can
also expierience delays when opening plug-ins
in the wrong order, interrupting the signal flow
when you work in the host program or similar things.