Forums > MaxMSP

Are send~ and receive~ really that expensive?

February 1, 2006 | 11:28 pm

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


February 2, 2006 | 12:13 am

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


February 2, 2006 | 9:37 am

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.

>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 2, 2006 | 1:17 pm

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


February 2, 2006 | 5:35 pm


February 2, 2006 | 6:55 pm

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


February 2, 2006 | 7:25 pm

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.

:P

-funny 110


February 2, 2006 | 9:27 pm

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


February 3, 2006 | 8:18 am

> 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


February 3, 2006 | 9:45 am

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


February 3, 2006 | 10:03 am

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

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 3, 2006 | 11:49 am

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


February 3, 2006 | 12:04 pm

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

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 3, 2006 | 12:08 pm

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

>
————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html



f.e
February 3, 2006 | 12:15 pm

and for sending signals ?


February 3, 2006 | 12:49 pm

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-


February 3, 2006 | 12:54 pm

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


February 3, 2006 | 1:49 pm

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

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 3, 2006 | 3:14 pm

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-


February 3, 2006 | 3:37 pm

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


February 3, 2006 | 3:53 pm

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


February 3, 2006 | 4:15 pm

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-


February 3, 2006 | 4:53 pm

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.


February 3, 2006 | 5:05 pm


February 3, 2006 | 5:24 pm

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


February 3, 2006 | 6:21 pm

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


February 3, 2006 | 6:55 pm

To clarify:

#P toggle 142 63 15 0;
#P toggle 142 24 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 142 43 58 196617 metro 500;
#P newex 142 103 40 196617 t 1 i 0;
#P newex 299 184 39 196617 noise~;
#P number 142 85 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 142 274 186 307 0;
#P newex 92 243 34 196617 r ch0;
#P newex 202 241 34 196617 r ch1;
#P user ubumenu 157 125 100 196617 0 1 1 0;
#X add ch0;
#X add ch1;
#X prefix_set 0 0 0;
#X pattrmode 1;
#P newex 202 147 68 196617 prepend send;
#P newex 299 213 66 196617 forward ch0;
#P connect 8 2 5 0;
#P connect 8 0 5 0;
#P connect 9 0 11 0;
#P connect 10 0 9 0;
#P connect 7 0 0 0;
#P connect 11 0 6 0;
#P connect 8 1 2 0;
#P connect 2 1 1 0;
#P fasten 1 0 0 0 207 206 304 206;
#P connect 6 0 8 0;
#P connect 3 0 5 1;
#P connect 4 0 5 0;
#P window clipboard copycount 12;


AB


February 3, 2006 | 9:36 pm

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


February 3, 2006 | 11:19 pm

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

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 123 53 48 196617 loadbang;
#P user jsui 183 261 64 64 1 0 0 none;
#P newex 123 176 29 196617 sig~;
#P message 123 98 86 196617 200 , 2000 4000;
#P newex 123 153 40 196617 line 0.;
#P newex 123 197 52 196617 cycle~ 0.;
#P user gain~ 123 265 24 100 158 0 1.071519 7.94321 10.;
#P user ezdac~ 123 415 167 448 0;
#N vpatcher 20 74 620 474;
#P window setfont "Sans Serif" 9.;
#P message 159 128 36 196617 signal;
#P outlet 261 252 15 0;
#P newex 261 163 46 196617 / 2000.;
#P window linecount 1;
#P newex 159 199 27 196617 *~;
#P newex 176 162 64 196617 cycle~ 400.;
#P window linecount 0;
#P newex 159 104 112 196617 route signal;
#P outlet 159 257 15 0;
#P inlet 159 49 15 0;
#P connect 0 0 2 0;
#P connect 2 0 7 0;
#P connect 7 0 4 0;
#P connect 4 0 1 0;
#P connect 3 0 4 1;
#P connect 2 1 5 0;
#P connect 5 0 6 0;
#P pop;
#P newobj 123 233 70 196617 p bad_voodoo;
#P connect 8 0 5 0;
#P fasten 4 1 5 0 183 179 234 79 256 106 189 84;
#P connect 0 1 7 0;
#P connect 4 0 6 0;
#P fasten 4 0 0 0 161 176 161 185 180 194 180 220 142 227;
#P connect 2 0 1 0;
#P connect 2 0 1 1;
#P connect 3 0 0 0;
#P connect 6 0 3 0;
#P connect 5 0 4 0;
#P connect 0 0 2 0;
#P window clipboard copycount 9;


February 4, 2006 | 12:26 am

> 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

February 4, 2006 | 1:48 pm


February 5, 2006 | 2:02 pm

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.

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 5, 2006 | 9:25 pm

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


February 8, 2006 | 10:55 am

Andrew Benson wrote:
> To clarify:
>
> #P toggle 142 63 15 0;

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


February 8, 2006 | 1:21 pm


February 8, 2006 | 6:46 pm

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


February 8, 2006 | 6:56 pm


February 8, 2006 | 11:36 pm


February 9, 2006 | 10:03 am

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.


February 12, 2006 | 7:11 pm

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


February 13, 2006 | 3:19 am

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.


Viewing 42 posts - 1 through 42 (of 42 total)