MAX/MSP/Jitter vs Max4Live?

    Nov 24 2009 | 6:39 pm
    Hi All, I am trying to understand what (if any) undocumented limitations there are with Max4Live vs MAX/MSP/Jitter. I have read this ( and it would appear that Max4Live is MAX+MSP+Jittter with only those documented limitations.
    However the specific immediate use of Max4Live I have in mind for use within Ableton Live only will require use of one or more of the following types of objects: tcp send/recv udp send/recv or serial io, or exernal objects implemented by myself in C++ (which depends upon which approach will yield what I need).
    On the surface it looks like all of these should function given the stated limitations, however I dont want to be stuck down the line having paid for Max4Live then discovering in about 30 days time that actually I have wasted my money and should instead have just written VST plugins directly in C++ because non of these objects are uported by M4L on its own - quite simply, right now aint a great time to be spending money that I can pospone for a month or two.
    I will buy Max4Live eventually anyway for its audio capabilities etc, however right at this point in time I have a far more urgent need of enabling Live to communicate some automation paremeters from live clips to another application runing on the same or another computer. Max4Live seems to be a way of drastically spending up this dev process (compare to writing VST plugins and UIs for them etc to meet my current needs).
    Thanks all.

    • Nov 24 2009 | 7:23 pm
      I've done a fair bit of udp send/receive in M4L and it works. Some caution (aka deferlow) should be taken when calling live.api objects with messages from udp. I haven't encountered problems with 3rd party externals.
    • Nov 24 2009 | 7:26 pm
      Any external you write which works in Max will work in MFL. We have created no restrictions for this sort of thing.
      Also, network and serial port access works fine.
      The only limitations of the MFL-authorized version of MaxMSP are in the way that audio and MIDI IO work, which are restricted to Live as source or destination, and you cannot create standalone applications or collectives.
    • Nov 25 2009 | 12:30 am
      Great - thanks for the replies both - I only want to use this within Live - I am actually looking at being able to create controls clip in live that send parameters and potentionally note data (as triggers) to another pc that is running our lighting using some other software I wrote.
      When you say caution calling Live API with udp? I assume you are hinting this live might have a threading issue with such calls when they originate from a network handler thread (depending upon how the internals of max and max4live are implemented)?
    • Nov 25 2009 | 12:52 am
      Re: Live API vs UDP -- that's exactly it. I have found that sending a lot (hundreds) of messages via UDP to update api elements has gummed things up, temporarily hanging Max, Live, or Both. Getting them into a lower priority thread fixed things. I'm still a novice in this environment, so it is completely possible that my programming style is to blame. But it makes sense to me that UDP packets come in at a high priority and tying up Live with hundreds of high priority requests might be a "bad idea."
    • Nov 27 2009 | 6:38 pm
      Hi Andrew,
      I was slightly confused by the limitations info with M4L: understand that I/O is limited to thru Live, makes sense, but the question I have is, can you do 5.1/7.1 sound with M4L in Live? Or are you restricted to two channels of I/O only?
      Curious about this as one of my goals might be to use M4L with Live and Absynth 5 in surround mode, say -- just want to know if there are any restrictions if, for example, I try to output Absynth 5 in surround thru a Max audio effect.
      Thanks! Hope the question isn't muddled. :)
    • Nov 27 2009 | 6:53 pm
      At the moment there is no easy way to have 5.1/7.1 with M4L - Live does not have this feature (yet?) and M4L is bound to the I/O of Live (stereo output per track)
    • Nov 28 2009 | 1:03 am
      Ah! Yes -- that is the case, sorry.