dhjdhjdhj

I'm trying to understand the difference. I was reading about the [matrix~] object and came across references to [send~]/[receive~]

But I've been using the regular [send] and [receive] for sending audio around and they seem to work fine.

send-vs-send

send is for Max messages. send~ is for audio signals via MSP.

You can shorten send simply to s but you can't shorten send~ to s~ (for some weird reason).

send is for Max messages. send~ is for audio signals via MSP.
You can shorten send simply to s but you can't shorten send~ to s~ (for some weird reason).


Yes, I understand that is supposed to be the difference. But the point is (as I mentioned in my first post) that I have been using the regular [send] and [receive] for audio signals and it seems to be working fine.

Excellent --- that explains things very well --- thank you.

Interesting. Does it mean that send/receive can also be used for audio between M4L devices?

that linked-to post is not very helpful four years on... using send/receive (without tilde) for audio is not and has never been a 'supported feature'. so, the problem is, even if it happens to work right now, it is (apparently very) likely that it will break unceremoniously in some update one day without warning, and all your old patches will break with it. there are a couple of very quirky patching situations where using non-tilde s/r's for audio is a useful trick / hack, and one of those is gone now with Gen. in general it is (apparently) ill-advised. use send~ / receive~.

Interesting --- I've always considered send/receive to be the equivalent of just having actual wire connections ---- as far as I understand it, send~/receive~ is NOT equivalent to having wired connections because there is some extra behavior involved (e.g, one vector delay, dynamic routing) and is a little more costly.

Why does it have to go away? It's not hurting anything, is it?

Interesting --- I've always considered send/receive to be the equivalent of just having actual wire connections ---- as far as I understand it,  send~/receive~ is NOT equivalent to having wired connections because there is some extra behavior involved (e.g, one vector delay, dynamic routing) and is a little more costly.

Why does it have to go away? It's not hurting anything, is it?


using send/receive in max for live (I mean between 2 patch/device inside 2 different tracks) always gave me low quality results. indeed, it al depends on what you make moving through this wireless connections, but..

send and receive (no tilde) can be used for sending a jitter matrix but when the matrix comes out of the receive its patch cord no longer looks like a matrix - it looks like a regular patch cord (this is true for MSP signals as well). I've often wished there was a jit.send and jit.receive that would handle this more the way send~ and receive~ do.

I understand that there is a fundamental difference between the signal network of MSP and the messaging model of Max and that Jitter matrices aren't really sent through those cords - my point is one of communication and UI consistency.

send and receive (no tilde) can be used for sending a jitter matrix but when the matrix comes out of the receive its patch cord no longer looks like a matrix - it looks like a regular patch cord (this is true for MSP signals as well). I've often wished there was a jit.send and jit.receive that would handle this more the way send~ and receive~ do. 

I understand that there is a fundamental difference between the signal network of MSP and the messaging model of Max and that Jitter matrices aren't really sent through those cords - my point is one of communication and UI consistency.


this is related to an issue I am having. trying to send midi data to another track from an audio track (so I can send the loudness). Any thoughts? I was using send / receive and it seems ok but I am worried that in the real world it will fail

Send/receive across M4L devices works basically well in the real world, but you need to be aware of some limitations regarding time accuracy and throughput. In particular, jitter/latency may be around 10 ms, and sending more than 50 messages per second is problematic.

it is true that it is not officialy supported, but if something is working in

version 3,4,5 and 6 of max, i believe it will continue to work in version 7.

if [send] or [prepend] one day will refuse to take audio we will just complain

it is true that it is not officialy supported, but if something is working in
version 3,4,5 and 6 of max, i believe it will continue to work in version 7.

if [send] or [prepend] one day will refuse to take audio we will just complain
until they give it us back!

For what it's worth, it would appear that send and receive no longer work for Max 6.

I was seeing all sorts of errors in the Max Window suggesting I change send/receive to send~/receive~.

I had a bit of trouble doing this as Max 6 crashed a couple of times when I changed [r ...] to [receive~ ...] but eventually I got everything changed over and my vst patches started working again.

send/receive does work in Max 6 within the same main patcher. I am heavily dependent on it...;-) If it ever breaks, I either need a multicore audio alternative or I simply stick with the old version.

Max 6 introduced multiple audio chains. send/receive will simply send the message "signal" from an audio source to its destination while building the audio chain. The connection between several audio chains didn't exist before Max 6. If you create two seperate patchers you need to connect them with send~/receive~ now...

send/receive needs less CPU cycles to perform. In fact it does the same as a simple patch cord...

send/receive does work in Max 6 within the same main patcher. I am heavily dependent on it...;-) If it ever breaks, I either need a multicore audio alternative or I simply stick with the old version.
Max 6 introduced multiple audio chains. send/receive will simply send the message "signal" from an audio source to its destination while building the audio chain. The connection between several audio chains didn't exist before Max 6. If you create two seperate patchers you need to connect them with send~/receive~ now...
send/receive needs less CPU cycles to perform. In fact it does the same as a simple patch cord...

I don't really use it much within a single patcher as I depend very heavily on the use of abstractions and bpatchers (for UI) so that a single patcher never gets too big.

[send] vs [send~]