DonK

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.

I looked on maxobjects, but couldn't find anything.

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.

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


sendrecieve-audio-signals

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

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,

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

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

Chris Muir
cbm@well.com	
http://www.xfade.com

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.

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

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.

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.

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

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

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.

> Subject: Re: [maxmsp] send/recieve audio signals?

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

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

> Subject: [maxmsp] Re: send/recieve audio signals?

> Actually, the differences between send/receive and send~/receive~ are more

> 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

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

> 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

> I hope that helps, let me know if you have any more questions.

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

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

> (if it isn't zero overhead, 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

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.

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

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

> 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

Quote: Peter Castine wrote on Sun, 13 April 2008 09:36

> Quote: Roth wrote on Sun, 13 April 2008 06:36

> ----------------------------------------------------

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

> > (if it isn't zero overhead, 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.

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.

Quote: Peter Castine wrote on Sun, 13 April 2008 09:36
----------------------------------------------------
> Quote: Roth wrote on Sun, 13 April 2008 06:36
> ----------------------------------------------------
>
> > 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.

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.


The patch I'm working on now is an audio rate sequencer/synth/sample playback tool.

If I understand correctly, I should send~ my main sync phaser, and any other timing crucial signals, but send/recieve are good enough for any noncritical timing and/or non-control audio signals?

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?

So I think I have a basic idea.
The patch I'm working on now is an audio rate sequencer/synth/sample playback tool.
If I understand correctly, I should send~ my main sync phaser, and any other timing crucial signals, but send/recieve are good enough for any noncritical timing and/or non-control audio signals?

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?


Quote: DonK wrote on Sun, 13 April 2008 18:53

> The patch I'm working on now is an audio rate sequencer/synth/sample playback tool.

> If I understand correctly, I should send~ my main sync phaser, and any other timing crucial signals, but send/recieve are good enough for any noncritical timing and/or non-control audio signals?

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

Quote: DonK wrote on Sun, 13 April 2008 18:53
----------------------------------------------------
> So I think I have a basic idea.
> The patch I'm working on now is an audio rate sequencer/synth/sample playback tool.
> If I understand correctly, I should send~ my main sync phaser, and any other timing crucial signals, but send/recieve are good enough for any noncritical timing and/or non-control audio signals?

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


thanks everyone. i figured out everything i need to know for now about send vs send~ for now. It's definately cleaned up my spaghetti patching techniques. these objects and bpatcher are now my bff (best friends forever). And CPU load isn't bad right now so I'm sticking to jeanfrancois's rule for now. A sound piece of advice...

thanks everyone.  i figured out everything i need to know for now about send vs send~ for now.  It's definately cleaned up my spaghetti patching techniques.  these objects and bpatcher are now my bff (best friends forever).  And CPU load isn't bad right now so I'm sticking to jeanfrancois's rule for now.  A sound piece of advice...


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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Sorry...that's why I didn't include audio on/off switches.

> Subject: Re: [maxmsp] Re: send/recieve audio signals?

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

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