send~/receive~ facilities


    Aug 27 2006 | 9:52 am
    Hello,
    the non-audio send/receive benefit from a wonderful menu I love to
    use: an option-click shows all occurences of the objects using the
    corresponding variable through the patches. I expected to use the
    same tip with the audio version, but didn't succeed in: did I miss
    something? This possibility could be very useful for my messy audio
    patches! ;-)
    Thank you,
    kb

    • Aug 27 2006 | 10:30 am
      On 8/27/06, Karim Barkati wrote:
      >
      > Hello,
      >
      > the non-audio send/receive benefit from a wonderful menu I love to
      > use: an option-click shows all occurences of the objects using the
      > corresponding variable through the patches. I expected to use the
      > same tip with the audio version, but didn't succeed in: did I miss
      > something? This possibility could be very useful for my messy audio
      > patches! ;-)
      >
      > A lot of people don't know/realize that the regular send/receive can be
      used for audio just as well. It's even better on the cpu, because the audio
      isn't buffered like with send~/receive~. The only drawback is that you can't
      dynamically change the destinations. So for static audio connections you can
      use regular s/r pairs. If I got this right, regular s/r equals hardwired
      connections, audio s/r do not because of their buffering/dynamic routing
      capabilities. I guess this is also why the option-click menu isn't showing
      the locations.
      -thijs
    • Aug 27 2006 | 12:05 pm
    • Aug 27 2006 | 12:32 pm
      On 8/27/06, Karim Barkati wrote:
      >
      > That's incredible! My poor ibook G4 suffers a lot with the first following
      > test-patch (cpu=39%) using 25 pairs of send~/receive~, and turns back happy
      > with the second which uses send/receive pairs (cpu=0%)... I couldn't expect
      > such a difference!
      >
      that's cool. I really think this use of s/r deserves some propaganda in the
      docs. I was really surprised myself when I first heard about it. Even though
      the docs say send can have anything in it's inlet, most people don't realize
      this includes audio.
      > ps: just a little regret: signal patch cords stay black.
      >
      yeah, you'll just have to live with that:-) same goes for s/r video. If you
      find this confusing you can always name your s/r in a way that you'll know
      the datatype, like a_* for audio v_* for video etc.
      cheers, -thijs
    • Aug 27 2006 | 12:37 pm
      Well, no popup menu happens automatically. Someone spent some time
      writing code to make the popup menus pop up. The main reason why
      send~/receive~ don't have connection popup menus is because no one
      programmed them to do so.
      There is a technical secondary reason: plain vanilla send/receive are
      *internal* objects, their code lives inside the Mac application
      rather than as code modules in separate files. So they have access to
      functions and data structures in Max that may not be available for
      use by external objects. It seems a safe guess that this barrier is
      not insurmountable.
      The lack of connection popups for send~/receive has come up before,
      hopefully it's been duly noted by whomever is maintaining the
      objects, and hopefully it'll percolate up through the priority list.
      BTW, if you want to use non-MSP send/receive-style connections
      objects with dynamically changing destination, have a look at the
      forward object. Works just like send, just it intercepts the set
      message. Should work for signals, although I haven't tried it.
      -- Peter
      On 27-Aug-2006, at 12:30, Thijs Koerselman wrote:
      >
      > On 8/27/06, Karim Barkati wrote: Hello,
      >
      > the non-audio send/receive benefit from a wonderful menu I love to
      > use: an option-click shows all occurences of the objects using the
      > corresponding variable through the patches. I expected to use the
      > same tip with the audio version, but didn't succeed in: did I miss
      > something? This possibility could be very useful for my messy audio
      > patches! ;-)
      >
      > A lot of people don't know/realize that the regular send/receive
      > can be used for audio just as well. It's even better on the cpu,
      > because the audio isn't buffered like with send~/receive~. The only
      > drawback is that you can't dynamically change the destinations. So
      > for static audio connections you can use regular s/r pairs. If I
      > got this right, regular s/r equals hardwired connections, audio s/r
      > do not because of their buffering/dynamic routing capabilities. I
      > guess this is also why the option-click menu isn't showing the
      > locations.
      >
      > -thijs
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Aug 27 2006 | 6:01 pm
      I just tried replacing all of my send~/receive~ pairs and reduced my
      cpu load form 39% to around 22% - yeah! - sort of ...
      Unfortunately I'm now getting lots of error messages (and I didn't
      make a copy of the patch first - d**m).
      Stuff like:
      toggle: doesn't understand "signal"
      signal outlet [*~] connected to nonsignal inlet [*~]
      and there was a bunch of stuff about connecting to a nonsignal inlet
      on meter~, biquad~ tap.limi~ & so on, which I fixed by making one of
      each of the s/r pair back into a signal object.
      So what's the deal when using s/r in this way? Are there limits as to
      what you can connect the receive part to? Or is this because I've
      tried converting an existing patch rather than building it this way?
      It would be incredibly good if I could use the s/r pair in this way
      (saves having to buy a faster computer!), but there's something not
      quite right.
      Any pointers?
      thanks
      David
    • Aug 27 2006 | 7:28 pm
      On 8/27/06, David Stevens wrote:
      >
      >
      > So what's the deal when using s/r in this way? Are there limits as to
      > what you can connect the receive part to? Or is this because I've
      > tried converting an existing patch rather than building it this way?
      >
      > It would be incredibly good if I could use the s/r pair in this way
      > (saves having to buy a faster computer!), but there's something not
      > quite right.
      There is no restriction to s/r, nor is there a problem with how they
      operate, you just connected the wrong things together. With regular
      patchcords max wont let you connect an audio outlet to a toggle, but with
      s/r there no way to check what you are about to send. You'll have to make
      sure you know what goes where. All or the error messages are created by
      false combinations s/r. Take a good look at the patch and if the connection
      are complicated try to use names that make sense.
      -thijs
    • Aug 27 2006 | 7:50 pm
      >
      >It would be incredibly good if I could use the s/r pair in this way
      >(saves having to buy a faster computer!), but there's something not
      >quite right.
      >
      >
      >There is no restriction to s/r, nor is there a problem with how they
      >operate, you just connected the wrong things together. With regular
      >patchcords max wont let you connect an audio outlet to a toggle, but
      >with s/r there no way to check what you are about to send. You'll
      >have to make sure you know what goes where. All or the error
      >messages are created by false combinations s/r. Take a good look at
      >the patch and if the connection are complicated try to use names
      >that make sense.
      maybe a simple thing, when building you patch would be to follow each
      [r] object with a [*~ 1] - or even encapsulate both as [r~] - so
      you'll keep the audio cords... (of course once it works, and if you
      feel the [r~] eats more cpu than [r] you could edit it
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Aug 27 2006 | 9:09 pm
      u run into your errors and high CPU usage because you
      prolly put more than one signal into your send~s.
      mix them together with a +~ or *~, this should stop it.
    • Aug 27 2006 | 11:48 pm
      On 27 Aug 2006, at 22:09, Roman Thilenius wrote:
      >
      > u run into your errors and high CPU usage because you
      > prolly put more than one signal into your send~s.
      Off the top of my head (it's late!) I'm pretty sure that I haven't
      done that - there's just a lot going on. I'm using train~ to control
      everything (first time I've tried this) and there's also lots of
      messages going out to my motormix (I've turned it into a half-sized
      monome, as I can't afford the real thing right now!) CPU is up around
      40% and the UI is slowing down a lot. And that's with sr at 32k and a
      few of the modules in downsampling poly~s!
      Anyway ...
      The thing with the error messages is - all I did was replace existing
      send~/receives~ with send/receive by simply deleting the tilde (~) in
      each object. And suddenly I had all these illegitimate connections
      (and I don't think I would have had any signals deliberately running
      into toggles anyway - not the sort of thing I'd do!).
      The weird thing now is - I turned all the s/r's back into signal
      objects - and I'm still getting the toggle error message. I've been
      through all of the subpatchers several times and can't see anything
      wrong. It looks like something re-wired itself somewhere. Or something.
      Oh well - try again with a fresh head tomorrow - and maybe have to
      rebuild stuff. Sigh.
      G'night
      David
    • Aug 27 2006 | 11:58 pm
      Couldn't let it go ...
      Traced it down to one module, which at one point had toggles in it
      (to test messages received) but which I'd removed. Very odd. I cut &
      pasted the patcher contents to a new empty patch & saved it under the
      old name & the problem cleared up.
      On 28 Aug 2006, at 0:48, David Stevens wrote:
      >
      > On 27 Aug 2006, at 22:09, Roman Thilenius wrote:
      >
      >>
      >> u run into your errors and high CPU usage because you
      >> prolly put more than one signal into your send~s.
      >
      > Off the top of my head (it's late!) I'm pretty sure that I haven't
      > done that - there's just a lot going on. I'm using train~ to
      > control everything (first time I've tried this) and there's also
      > lots of messages going out to my motormix (I've turned it into a
      > half-sized monome, as I can't afford the real thing right now!) CPU
      > is up around 40% and the UI is slowing down a lot. And that's with
      > sr at 32k and a few of the modules in downsampling poly~s!
      >
      > Anyway ...
      >
      > The thing with the error messages is - all I did was replace
      > existing send~/receives~ with send/receive by simply deleting the
      > tilde (~) in each object. And suddenly I had all these illegitimate
      > connections (and I don't think I would have had any signals
      > deliberately running into toggles anyway - not the sort of thing
      > I'd do!).
      >
      > The weird thing now is - I turned all the s/r's back into signal
      > objects - and I'm still getting the toggle error message. I've been
      > through all of the subpatchers several times and can't see anything
      > wrong. It looks like something re-wired itself somewhere. Or
      > something.
      >
      > Oh well - try again with a fresh head tomorrow - and maybe have to
      > rebuild stuff. Sigh.
      >
      > G'night
      >
      > David
      >
      >
    • Aug 28 2006 | 10:54 am
      On 27 Aug 2006, at 20:28, Thijs Koerselman wrote:
      > There is no restriction to s/r, nor is there a problem with how
      > they operate, you just connected the wrong things together. With
      > regular patchcords max wont let you connect an audio outlet to a
      > toggle, but with s/r there no way to check what you are about to send.
      and kasper added
      >maybe a simple thing, when building you patch would be to follow
      each [r] object with a [*~ 1] - or even
      >encapsulate both as [r~] - so you'll keep the audio cords... (of
      course once it works, and if you feel the [r~] eats
      >more cpu than [r] you could edit it
      I'd really like to get to the bottom of this ...
      I fixed all the problems created by my first impetuous attempt, and
      then simply replaced the stereo outs of each module ...
      output object of each module to send instead of send~
      eg [*~ 1.] -> [send seq_playerL]
      or
      [wave~ #1] (inside subpatcher - via outlet) -> [send lprcd1]
      and the related receive in the output mixer ...
      [receive seq_playerL] - which is already connected to a [*~ 1.]
      [receive lprcd1] - which is already connected to a [*~ 1.]
      Then I fired up the main patch, turned on audio, and got 8 times ...
      error: signal outlet (*~) connected to nonsignal inlet (*~)
      So I'm going from signal object to send; then receive to [*~ ] -
      and still getting an error message.
      Que pasa?
      David
    • Aug 28 2006 | 11:26 am
      >
      >
      >So I'm going from signal object to send; then receive to [*~ ] -
      >and still getting an error message.
      >
      >Que pasa?
      don't know
      something like this works (without the encapsulation, of course) -
      and the *~ 1 after "noise" is of course useless)
      best
      kasper
      #P user ezdac~ 397 214 441 247 0;
      #P user meter~ 266 200 346 213 50 0 168 0 103 103 103 255 153 0 255 0
      0 217 217 0 153 186 0 12 3 3 3 3;
      #P window setfont "Sans Serif" 9.;
      #P window linecount 1;
      #P newex 266 156 32 196617 *~ 1;
      #P newex 266 121 41 196617 r noise;
      #P newex 125 203 41 196617 s noise;
      #P newex 125 173 32 196617 *~ 1;
      #P newex 125 118 39 196617 noise~;
      #P connect 4 0 5 0;
      #P connect 3 0 4 0;
      #P connect 1 0 2 0;
      #P connect 0 0 1 0;
      #P window clipboard copycount 7;
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Aug 28 2006 | 11:27 am
      SOLVED (some of) IT!! (I think)
      The offending sends were inside [poly~ xxxx down 2].
      I brought them outside into the interface part of the patch ( *~ ->
      out~ -> send) and the problem went away.
      So it looks like replacing send~ with s doesn't work from inside a poly~
      Or maybe (which seems more likely to me now I think about it) it's
      the downsampling? As the receiving part of the patcher (the output
      mixer) isn't downsampled.
      David
      >
      > On 27 Aug 2006, at 20:28, Thijs Koerselman wrote:
      >
      >
      >
      >> There is no restriction to s/r, nor is there a problem with how
      >> they operate, you just connected the wrong things together. With
      >> regular patchcords max wont let you connect an audio outlet to a
      >> toggle, but with s/r there no way to check what you are about to
      >> send.
      >>
      >
      >
    • Aug 28 2006 | 11:56 am
      On 8/28/06, David Stevens wrote:
      >
      > SOLVED (some of) IT!! (I think)
      >
      > The offending sends were inside [poly~ xxxx down 2].
      > I brought them outside into the interface part of the patch ( *~ ->
      > out~ -> send) and the problem went away.
      >
      > So it looks like replacing send~ with s doesn't work from inside a poly~
      > Or maybe (which seems more likely to me now I think about it) it's
      > the downsampling? As the receiving part of the patcher (the output
      > mixer) isn't downsampled.
      >
      > Yeah I forgot about poly~. I've had and solved issues with poly regarding
      the same problem in the past, but I can't remember what the outcome was.
      Like you said it's unlikely for this to work when sending audio in and out
      of poly~. Especially if you're up/down sampling. That wouldn't make much
      sense. So I guess my statement about no limitations wasn't correct after
      all.
      Good to hear you solved the problems.
      cheers, -thijs
    • Aug 31 2006 | 3:35 pm
      First some explanation (as always acceptng that i may have remembered something wrong - but to the best of my recollection).....
      send~ and receive~ work by copying the input(s) to send~ to a new location in memory for each receive (that's the cpu expense). In addition, you "may" inccur a vectors delay when using send~ receive~s. This depends on the order the dsp chain compiles which is often hard (or impossible) to determine without just trying any given case (and i think also on whether you are communicating between a poly~ and the outside world).
      When you use send / receive (s/r) to send a signal you are taking advantage of the fact tha dsp chain compilation is actually actually acheived by signal objects sending the 'signal' message out of each outlet in turn (each object triggering the next). This message (as it is a max message) can travel through send and receive and thus it is equivalent to hard patching objects to one another. Signal patch cords are merely a way of the signal message being sent between objects, once the dsp is on, they play no part in the transfer of audio. However, as others have noted about s/r instead, max has no way of telling that you are using the s/r objects in this way and you might get error messages.
      So to poly~...
      > So it looks like replacing send~ with s doesn't work from inside a poly~
      > Or maybe (which seems more likely to me now I think about it) it's
      > the downsampling? As the receiving part of the patcher (the output
      > mixer) isn't downsampled.
      poly~ (and pfft~) have their own dsp chains (that's how you can downsample etc.) which are called internally, possibly at a different rate to the main dsp chain. The c74 guys must have made send~ and receive~ aware of this, so they deal with it properly - other than this there will be problems because you are trying to get two different dsp chains to communicate with each other as if you were hard-patching one dsp chain to the other - which max will not like. So this will probably never work.....
      Alex
    • Aug 31 2006 | 3:58 pm
      Thanks Alex,
      That makes it much clearer. In fact I solved the problem by taking
      the send~s outside of the downsampled poly~. For now I gave up on
      using send - there were too many other routing things going on that
      made it not work.
      David