eirik.lie

I'm an old Max user, only recently started using MSP seriously.

You can double-click on the Max send/receive objects and get a list 

of what other subpatchers are using send/receive objects with the 

same name. However, you can't do that with the MSP send~/receive~ 

Eirik Lie, Bjornerabben 9, N-0383 Oslo, Norway

Email: eirik.lie@notam02.no - Tel +47 22 50 23 14 / +47 90 67 18 17

http://home.online.no/~eiriklie/Visual.html

http://home.online.no/~eiriklie/CX5MFAQ.html

I'm an old Max user, only recently started using MSP seriously.
You can double-click on the Max send/receive objects and get a list 
of what other subpatchers are using send/receive objects with the 
same name. However, you can't do that with the MSP send~/receive~ 
objects. Or am I missing something?

-- 
Eirik Lie, Bjornerabben 9, N-0383 Oslo, Norway
Email: eirik.lie@notam02.no   -   Tel +47 22 50 23 14 / +47 90 67 18 17
Check out my CD "12 Bilder": http://home.online.no/~eiriklie/Visual.html
Yamaha CX5M FAQ: http://home.online.no/~eiriklie/CX5MFAQ.html


sendsend

Quote: eirik.lie wrote on Sat, 10 November 2007 16:50

----------------------------------------------------

> I'm an old Max user, only recently started using MSP seriously.

> You can double-click on the Max send/receive objects and get a list 

> of what other subpatchers are using send/receive objects with the 

> same name. However, you can't do that with the MSP send~/receive~ 

That's true. And it's a shame.. Same holds for forward and pattr and pv.

Quote: eirik.lie wrote on Sat, 10 November 2007 16:50
----------------------------------------------------
> Hello,
>
> I'm an old Max user, only recently started using MSP seriously.
> You can double-click on the Max send/receive objects and get a list 
> of what other subpatchers are using send/receive objects with the 
> same name. However, you can't do that with the MSP send~/receive~ 
> objects. Or am I missing something?
>

Maybe you can use [send] and [receive] for signals then ... provided that you are making static signal sends and receives

>Maybe you can use [send] and [receive] for signals then ... provided 

>that you are making static signal sends and receives

You're right! I just discovered: [send] and [receive] (without the 

tilde~) can send and receive audio signals! What's the catch? Is this 

a bug or a feature? No need for using [send~] and [receive~] then? 

>Hello,
>
>Maybe you can use [send] and [receive] for signals then ... provided 
>that you are making static signal sends and receives

You're right! I just discovered: [send] and [receive] (without the 
tilde~) can send and receive audio signals! What's the catch? Is this 
a bug or a feature? No need for using [send~] and [receive~] then? 
But what do you mean by "static signal"?

> You're right! I just discovered: [send] and [receive] (without the 

> tilde~) can send and receive audio signals! What's the catch? Is this a 

> bug or a feature? No need for using [send~] and [receive~] then? But 

Its a feature. send/receive without tilde is exactly like a connection 

with a cord. But in audio it will be only examined when you switch on 

audio, to build the DSP chain. You can't use it for scripting. (that 

refers to static). You can't use them if your audio chain creates a 

feedback. send~/receive~ will introduce a signal vector of delay for 

that purpose (only if there is a feedback...)

send/receive won't work across DSP chains. poly~ and pfft~ will create 

Eirik Lie schrieb:
> You're right! I just discovered: [send] and [receive] (without the 
> tilde~) can send and receive audio signals! What's the catch? Is this a 
> bug or a feature? No need for using [send~] and [receive~] then? But 
> what do you mean by "static signal"?

Its a feature. send/receive without tilde is exactly like a connection 
with a cord. But in audio it will be only examined when you switch on 
audio, to build the DSP chain. You can't use it for scripting. (that 
refers to static). You can't use them if your audio chain creates a 
feedback. send~/receive~ will introduce a signal vector of delay for 
that purpose (only if there is a feedback...)
send/receive won't work across DSP chains. poly~ and pfft~ will create 
their own DSP chains...

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

Besides what Stefan explained, thanks to the [set( message you can change at any time which [receive~] a [send~] is sending the signal to, and which [send~] a [receive~] is receiving the signal from.

This dynamic routing is not possible with [send] and [receive]. If the routing doesn't have to change, or if it is done differently (for example, using a kind of mixer in the patch), I use [send] and [receive]. I have no idea if it's a good practice, but it seems to work and it saves some CPU load compared to [send~] and [receive~].

using [forward] or setting [receive] don't work for signals

On 13 nov. 07, at 11:47, julienbreval wrote:

> using [forward] or setting [receive] don't work for signals

It's not entirely true. If you use send message on [forward], and set 

message on [receive] BEFORE turning on the audio, it's gonna work. 

Just remember that [send]/[receive] act like a normal cable 

connection. When you make a new connection while the dsp is on, Max 

will automatically turn off the dsp, and put it back on afterward, 

which is something which is not done automatically for you when you 

change the source/desitination of a [forward]/[receive].

To summarize, you can use [send]/[receive] in the same condition as 

place where you could use a simple connection. [send~]/[receive~] 

takes more CPU, but allows you to dynamically change source/ 

destination, to automatically had a vector size delay when necessary 

(look at the archive for more details about that).

It's not entirely true. If you use send message on [forward], and set  
message on [receive] BEFORE turning on the audio, it's gonna work.  
Just remember that [send]/[receive] act like a normal cable  
connection. When you make a new connection while the dsp is on, Max  
will automatically turn off the dsp, and put it back on afterward,  
which is something which is not done automatically for you when you  
change the source/desitination of a [forward]/[receive].

To summarize, you can use [send]/[receive] in the same condition as  
place where you could use a simple connection. [send~]/[receive~]  
takes more CPU, but allows you to dynamically change source/ 
destination, to automatically had a vector size delay when necessary  
(look at the archive for more details about that).

send/send~