Are send~ and receive~ really that expensive?


    Feb 01 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

    • Feb 02 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
    • Feb 02 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
    • Feb 02 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
    • Feb 02 2006 | 5:35 pm
    • Feb 02 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
    • Feb 02 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
    • Feb 02 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
    • Feb 03 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
    • Feb 03 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
    • Feb 03 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
    • Feb 03 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
    • Feb 03 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
    • Feb 03 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
    • Feb 03 2006 | 12:15 pm
      and for sending signals ?
    • Feb 03 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-
    • Feb 03 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
    • Feb 03 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:
      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
    • Feb 03 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-
    • Feb 03 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
    • Feb 03 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
    • Feb 03 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-
    • Feb 03 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.
    • Feb 03 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.
    • Feb 03 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.
    • Feb 03 2006 | 6:55 pm
      To clarify:
      -- AB
    • Feb 03 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
    • Feb 03 2006 | 11:19 pm
      These seems relevant to the difference between send~ and send.
    • Feb 04 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!
    • Feb 04 2006 | 11:28 am
      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
    • Feb 04 2006 | 1:48 pm
    • Feb 05 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
    • Feb 05 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*
    • Feb 08 2006 | 10:55 am
      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
    • Feb 08 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
    • Feb 08 2006 | 6:56 pm
    • Feb 09 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.
    • Feb 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 ??
    • Feb 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.