send/recieve audio signals?

DonK,

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

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

Ahh, that's what I was missing.
I just saw the grey bogus object looking box and thought it didn't exist. I'm starting to realize how important the Max window can be.

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

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

Thanks for the info, Roth.

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~?

That's exactly what I meant! Thanks a lot. My students end up pointing out really obvious stuff like that from time to time too. I guess coming from PureData, I never really bothered to learn all the stuff about Max that could make my life easier--I just keep charging forward trying to come up with more and more of my own complicated synthesis and interface designs.

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 :)

Funnel and route also work for multichannel send/receive of audio. Someone
suggested it on the list a year or so ago and I use it a lot for sending 4-8
channels. Much neater than a bunch of send~/receive~ objects.

Cheers
Gary Lee Nelson
Oberlin College
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
>
>
>
>
>
>

Like this...

Cheers
Gary Lee Nelson
Oberlin College
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

Quote: Roth wrote on Sun, 13 April 2008 06:36
----------------------------------------------------
> Actually, the differences between send/receive and send~/receive~ are more in-depth than this.

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.