Nov 24, 2009 at 5:49pm


It seems that there is no global send~ and receive~ from an instance to another (ex.: when I have 2 patches on the tracks).
Is there a way to take the audio of a track and use it in the patch of another track?
Thanks a lot!!

Nov 25, 2009 at 11:18am

You are right, the send~ is not working within maxforlive.

Stefan Tiedje already suggested a live.out~ multi-channel-object ( , which I think would be a perfect solution for spatialization or multi-channel audio. I could work exactly like the “audio to” function in Live itself and would overcome the limitations of the stereo-out of maxforlive.

Nov 25, 2009 at 7:09pm

send~/receive~ between devices didn’t make it into the first version of Max for Live, but we are definitely looking at a solution for future updates. We know this is something a lot of people want to do, and it is high on our list of features to implement.
If you don’t mind introducing a bunch of latency in the sending, you might be able to hack together a buffer~ based solution.

Nov 26, 2009 at 11:54am

Thank you Andrew, that is good to know, that you are working on it !

Nov 26, 2009 at 12:42pm

Good thing to know!

Nov 28, 2009 at 4:01pm


[plugsend~] and [plugreceive~] seem to work here.

can you confirm we can use it without problem ?

send :

– Pasted Max Patch, click to expand. –

receive :

– Pasted Max Patch, click to expand. –
Nov 30, 2009 at 8:46pm

It Works!

Dec 1, 2009 at 4:47am

I double-checked. Here’s the current skinny:

Dec 8, 2009 at 9:45am

Gosh, this is a huge wall. Nearly all i figured to do with m4l was send~/receive~ related.

What about send/receive ? Coll ?

Dec 8, 2009 at 2:06pm

send/receive and coll are more or less fine. Let me explain the more or less a bit… It’s likely that the devices are in different threads, so with send/receive you will get an unknown latency, with coll you might try to access some data in one device while you clear the same coll at the same time in another device, and there’s no protection against that.

Dec 8, 2009 at 5:28pm

I have two questions about send/receive:

a) Is it possible to estimate an upper limit of the latency?

b) Could it be that OSC messages provide better timing?


Dec 8, 2009 at 7:05pm

a) it shouldn’t be too much, but it’s unpredictable
b) nope


Dec 9, 2009 at 12:50pm

So it means, for the time beeing that you cannot build a step sequencer which would send triggers to instruments that are on other tracks.

And you cannot build a big Max device which would have multiple outputs you could route to Live tracks.

And you may not rely on send/receive to make your Max devices talk together.

Are these things on the dev list for further release of m4l ?

Best wishes


Dec 9, 2009 at 11:44pm

One of the cool things I like in Live is the Instruments (Audio / MIDI Effects) Racks. You can use a Step sequencer and still use 4 different synths for instance. Communication between Max for Live devices using send and receive is supported, but there may be some latency involved when sending data between devices. Multithreading is tricky… c’est la vie.

Dec 11, 2009 at 6:45am

i’m assuming (based on the above, and the fact that the only signal-rate MSP devices are live.remote~ and live.param~) that there is no way to to tap into the audio output of another track *without* having a separate M4L device in that track (i.e. via the API).

is this sort of thing possible in principle (signal-rate audio reading directly through the API)? with a platform like M4L, it would be highly beneficial for the purpose of sharing devices to be able to keep things as self-contained as possible. for instance, i’m working on a patch that would ideally operate globally, within the master track, but be able to read audio from other tracks (for analysis purposes), and not be dependent on the rest of the set being configured any particular way.

any thoughts on this? i don’t consider it critical to my projects, but it would be a big step up in my mind to be able to do this eventually.


You must be logged in to reply to this topic.