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| http://www.dspaudio.com/ http://www.castine.de
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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