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