Forums > MaxMSP

send~/receive~ facilities


kb
August 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


August 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



kb
August 27, 2006 | 12:05 pm


August 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


August 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


August 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


August 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


August 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


August 27, 2006 | 9:03 pm


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


August 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


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


August 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


August 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


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


August 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


August 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


August 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


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