Forums > Max For Live

Send~


pm
November 24, 2009 | 5:49 pm

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


November 25, 2009 | 11:18 am

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

Stefan Tiedje already suggested a live.out~ multi-channel-object (http://forum.ableton.com/viewtopic.php?f=35&t=129706) , 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.


November 25, 2009 | 7:09 pm

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.


November 26, 2009 | 11:54 am

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



pm
November 26, 2009 | 12:42 pm

Good thing to know!



FP
November 28, 2009 | 4:01 pm

Hi,

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

can you confirm we can use it without problem ?
thx.

send :

– Pasted Max Patch, click to expand. –

receive :

– Pasted Max Patch, click to expand. –

November 30, 2009 | 8:46 pm

It Works!


December 1, 2009 | 4:47 am

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

http://forum.ableton.com/viewtopic.php?p=1030931#p1030931



f.e
December 8, 2009 | 9:45 am

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

What about send/receive ? Coll ?


December 8, 2009 | 2:06 pm

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.


December 8, 2009 | 5:28 pm

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?

Thanks.


December 8, 2009 | 7:05 pm

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

Cheers



f.e
December 9, 2009 | 12:50 pm

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

f.e


December 9, 2009 | 11:44 pm

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.


December 11, 2009 | 6:45 am

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.


Viewing 15 posts - 1 through 15 (of 15 total)