I looked on maxobjects, but couldn’t find anything.
Thanks.

You need a name argument. Try typing [send~ test] & [receive~ test]. It will
work, they are there. If you notice your max window when you type just
[send~], it doesn’t say “no such object”. It says “requires name argument”.
Best,

Ken

send and receive work for audio signals, and there is also send~ and
receive~, which have the advantage/disadvantage of delaying by one
signal vector (this can be useful in some patches).

-C

Chris Muir
cbm@well.com

http://www.xfade.com

Thanks. I’ll try to pay more attention next time.

Whether you are using send/receive with Max data or MSP signals, this is essentially the same as using a cable connection. At runtime, Max evaluates [send]s/[receive]s as cable connections. As far as I know this means there is no processor overhead for using [send]/[receive] vs. a cable connection. I may be incorrect on the exact operation of how [send]/[receive] is evaulated (if it isn’t zero overhead, it is very little) so someone please correct me if you can offer a better description.

What I am sure is what this means for differences between using [send] vs [send~].

There are two limitations to using send/receive with MSP signals:

1. Since [send]/[receive] is like making a cable connection, you cannot reroute your [send]/[receive]s for MSP signals while DSP is turned on.

2. You cannot [send]/[receive] MSP signals across different DSP chains (both [poly~] and [pfft~] create separate DSP chains.

The first advantage of [send~] and [receive~] is that it can do both these things that [send]/[receive] can’t (i.e. you can both rename to reroute while DSP is on and you can send across chains).

The other advantage of [send~]/[receive~] Chris mentioned, but there is more to it than that. [send~]/[receive~] do add a signal vector of delay, BUT ONLY if it is necessary to avoid a logical impossibility created by a feedback loop (e.g. it is impossible to connect an MSP outlet to an inlet because you would be asking the object to process information that has not be generated yet). If there is no feedback loop involved, [send~]/[receive~] adds zero delay. At some point, a patch proving this was posted, but I couldn’t find it.

While [send~]/[receive~] has a lot more powerful features, it will take more processor power than [send]/[receive]. So save [send~]/[receive~] only for when you need one of these three features not covered by [s]/[r].

Unfortunately, there is no [s~]/[r~] like there is in PureData. I’m REALLY hopping they add that to Max 5.

I hope that helps, let me know if you have any more questions.
Quote: Chris Muir wrote on Sat, 12 April 2008 21:09
—————————————————-
>
> On Apr 12, 2008, at 6:15 PM, Don K wrote:
> > Is there anything like send and recieve, but for an audio signal?
> > My patch is getting tooooooo messy and could use some cleanup using
> > something like a send~/recieve~ set of objects.
>
>
> send and receive work for audio signals, and there is also send~ and
> receive~, which have the advantage/disadvantage of delaying by one
> signal vector (this can be useful in some patches).
>
> -C
>
> Chris Muir
> cbm@well.com
> http://www.xfade.com
>
>
>
>
>
>
>
—————————————————-

I’m not sure if this is what you mean at the end, but you can add your own “shortcut/alias” by editting the audio-objectmappings.txt file.

I added these two lines, seems to work.

max objectfile s~ send~;
max objectfile r~ receive~;

Is that what you meant by s~ and r~?

Thanks for reminding me of a feature I vaguely knew existed and never bothered to read up on….now that my class is over I guess I really should study up on all the stuff I could be doing to make my life easier before next time :)

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

> From: Chris Muir
> Reply-To:
> Date: Sat, 12 Apr 2008 20:09:24 -0700
> To:
> Subject: Re: [maxmsp] send/recieve audio signals?
>
>
> On Apr 12, 2008, at 6:15 PM, Don K wrote:
>> Is there anything like send and recieve, but for an audio signal?
>> My patch is getting tooooooo messy and could use some cleanup using
>> something like a send~/recieve~ set of objects.
>
>
> send and receive work for audio signals, and there is also send~ and
> receive~, which have the advantage/disadvantage of delaying by one
> signal vector (this can be useful in some patches).
>
> -C
>
> Chris Muir
> cbm@well.com
> http://www.xfade.com
>
>
>
>
>
>

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 38 102 44 196617 s signal;
#P newex 38 190 67 196617 dac~ 1 2 3 4;
#P newex 38 164 87 196617 route 0 1 2 3;
#P newex 38 142 44 196617 r signal;
#P newex 38 76 53 196617 funnel 4;
#P newex 38 49 67 196617 adc~ 1 2 3 4;
#P connect 3 3 4 3;
#P connect 3 2 4 2;
#P connect 3 1 4 1;
#P connect 3 0 4 0;
#P connect 1 0 5 0;
#P connect 2 0 3 0;
#P connect 0 3 1 3;
#P connect 0 2 1 2;
#P connect 0 1 1 1;
#P connect 0 0 1 0;
#P window clipboard copycount 6;

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

> From: Roth Michaels
> Organization: Cycling ’74
> Reply-To:
> Date: Sat, 12 Apr 2008 22:36:40 -0600
> To:
> Subject: [maxmsp] Re: send/recieve audio signals?
>
>
> Actually, the differences between send/receive and send~/receive~ are more
> in-depth than this.
>
> Whether you are using send/receive with Max data or MSP signals, this is
> essentially the same as using a cable connection. At runtime, Max evaluates
> [send]s/[receive]s as cable connections. As far as I know this means there is
> no processor overhead for using [send]/[receive] vs. a cable connection. I
> may be incorrect on the exact operation of how [send]/[receive] is evaulated
> (if it isn’t zero overhead, it is very little) so someone please correct me if
> you can offer a better description.
>
> What I am sure is what this means for differences between using [send] vs
> [send~].
>
> There are two limitations to using send/receive with MSP signals:
>
> 1. Since [send]/[receive] is like making a cable connection, you cannot
> reroute your [send]/[receive]s for MSP signals while DSP is turned on.
>
> 2. You cannot [send]/[receive] MSP signals across different DSP chains (both
> [poly~] and [pfft~] create separate DSP chains.
>
> The first advantage of [send~] and [receive~] is that it can do both these
> things that [send]/[receive] can’t (i.e. you can both rename to reroute while
> DSP is on and you can send across chains).
>
> The other advantage of [send~]/[receive~] Chris mentioned, but there is more
> to it than that. [send~]/[receive~] do add a signal vector of delay, BUT ONLY
> if it is necessary to avoid a logical impossibility created by a feedback loop
> (e.g. it is impossible to connect an MSP outlet to an inlet because you would
> be asking the object to process information that has not be generated yet).
> If there is no feedback loop involved, [send~]/[receive~] adds zero delay. At
> some point, a patch proving this was posted, but I couldn’t find it.
>
> While [send~]/[receive~] has a lot more powerful features, it will take more
> processor power than [send]/[receive]. So save [send~]/[receive~] only for
> when you need one of these three features not covered by [s]/[r].
>
> Unfortunately, there is no [s~]/[r~] like there is in PureData. I’m REALLY
> hopping they add that to Max 5.
>
> I hope that helps, let me know if you have any more questions.
> Quote: Chris Muir wrote on Sat, 12 April 2008 21:09
> —————————————————-
>>
>> On Apr 12, 2008, at 6:15 PM, Don K wrote:
>>> Is there anything like send and recieve, but for an audio signal?
>>> My patch is getting tooooooo messy and could use some cleanup using
>>> something like a send~/recieve~ set of objects.
>>
>>
>> send and receive work for audio signals, and there is also send~ and
>> receive~, which have the advantage/disadvantage of delaying by one
>> signal vector (this can be useful in some patches).
>>
>> -C
>>
>> Chris Muir
>> cbm@well.com
>> http://www.xfade.com
>>
>>
>>
>>
>>
>>
>>
> —————————————————-
>
>
> –
>
> Roth Michaels
> ————-
> roth@rothmichaels.us
> http://www.rothmichaels.us

Correct.

> Whether you are using send/receive with Max data or MSP signals, this is essentially the same as using a cable connection. At runtime, Max evaluates [send]s/[receive]s as cable connections.

Not quite correct.

> (if it isn’t zero overhead, it is very little)

It is very little.

I have written code for sending messages to receive objects (similar to how message box handles the semi-colon). If I describe exactly what happens we will probably find the thread moved to the dev list, where the question “how do I program send/receive” has been discussed several times. The actual gory details are probably beyond the scope of this list.

> The other advantage of [send~]/[receive~] Chris mentioned, but there is more to it than that. [send~]/[receive~] do add a signal vector of delay, BUT ONLY if it is necessary to avoid a logical impossibility created by a feedback loop

An important point.

Yeah, I thought I read somewhere that it was like a cable connection, but I had a hard time believe that [send]/[receive] didn’t add anything for processor overhead. Thanks for stepping in and correcting me. Probably right about the thread moving, but I am curious about the exact differences between using cables vs. [send]/[receive] so I would love it if you have the time to explain this to me in a private email if not on the forum. NO RUSH though, I’m in the midst of many other projects as I am sure you are too Peter but this is something I’ve been curious about for a while and I can’t pass up the opportunity to ask someone who may know. So any time down the road if you have a chance to hip me up to this it would be very cool.

If I want to make something a bit modular, with signal patching on the fly, are the standard send/receive objects good enough for that? For example, I have a few bpatchers, one with a VCF type module, and two ADSRs. Eventually I want this to be a stand alone application, so editing the patch will not be possible.
Would I be better off setting the send name and using send~ rather than relying on the popup menu in s/r?

send/receive should be fine for timing critical signals. The only time you should run into problems is when you are creating feedback within your patch. Examples would be some kinds of feedback FM and feedback delay, etc. (this would be a logical impossibility with send/receive or a patch cable–this is when send~/receive~ decides you need to add one signal vector of delay). I realize this isn’t the best description, so if it isn’t clear maybe someone else can jump in or I can try again tomorrow when I have the extra neurons to dedicate to clarity.

> If I want to make something a bit modular, with signal patching on the fly, are the standard send/receive objects good enough for that? For example, I have a few bpatchers, one with a VCF type module, and two ADSRs. Eventually I want this to be a stand alone application, so editing the patch will not be possible.
> Would I be better off setting the send name and using send~ rather than relying on the popup menu in s/r?

If you want to reroute your signals on the fly while audio processing is turned on you MUST use send~/receive~. Using send/receive to reroute while dsp is on will turn dsp off (I think that is what happens, either way, avoid using s/r for dynamic rerouting of audio).
>
>
—————————————————-

Please don’t do this unless there is a gain~ (closed) in the example. If
you just open this on a powerbook you get immediately a high pitch
hurting feedback… (there is a mic and speakers ready to go…)

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

> From: Stefan Tiedje
> Reply-To:
> Date: Wed, 16 Apr 2008 17:00:09 +0200
> To:
> Subject: Re: [maxmsp] Re: send/recieve audio signals?
>
> Gary Lee Nelson schrieb:
>> Like this…
>
> Please don’t do this unless there is a gain~ (closed) in the example. If
> you just open this on a powerbook you get immediately a high pitch
> hurting feedback… (there is a mic and speakers ready to go…)
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>