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

    • Nov 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 ( , 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 | 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.
    • Nov 26 2009 | 11:54 am
      Thank you Andrew, that is good to know, that you are working on it !
    • Nov 26 2009 | 12:42 pm
      Good thing to know!
    • Nov 28 2009 | 4:01 pm
      [plugsend~] and [plugreceive~] seem to work here.
      can you confirm we can use it without problem ? thx.
      send :
      receive :
    • Nov 30 2009 | 8:46 pm
      It Works!
    • Dec 01 2009 | 4:47 am
      I double-checked. Here's the current skinny:
    • Dec 08 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 ?
    • Dec 08 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.
    • Dec 08 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?
    • Dec 08 2009 | 7:05 pm
      a) it shouldn't be too much, but it's unpredictable b) nope
    • Dec 09 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
    • Dec 09 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.
    • Dec 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.