Max for live VS max/msp

[bhc303]

Hi,

Is there any difference in the programs?

I understand the look and work flow in max 4 live is slightly different and the software is native to live so any devices created in max 4 live can only be used in max 4 live etc.

Can stand alone devices created in max/msp be used in Max 4 live and vise versa?

Other than the basics it's the same full piece of kit yeah? it can do everything the same as max msp just only inside live?

cheers

[broc]

It's basically the same but there are some limitations

http://www.cycling74.com/docs/max5/vign ... tions.html

[bhc303]

Thanks, will check it out

[trevox]

One thing that is not officially mentioned is the pathetic lack of midi functionality - i.e. not being able to send out multiple midi ports / channels from one patch. There are ways around this that involve third party externals, but I must say this was the most disappointing thing for me - very limiting.

[bhc303]

Is this in M4L or max/msp?

interesting!

Do you think this might be changed with the new max 6?

how hard is the routing with third party externals, what you using?

Not sure to go M4L or max/msp...

Cheers for reply!

[stringtapper]

One thing that is not officially mentioned is the pathetic lack of midi functionality - i.e. not being able to send out multiple midi ports / channels from one patch. There are ways around this that involve third party externals, but I must say this was the most disappointing thing for me - very limiting.

Is this in M4L or max/msp?

interesting!

Do you think this might be changed with the new max 6?

how hard is the routing with third party externals, what you using?

Not sure to go M4L or max/msp...

Cheers for reply!

This is not a limitation with Max/M4L but a limitation with Live itself, so until Live can handle internal and external multi midi routing it will not be solved, Max 6 or not.

[trevox]

One thing that is not officially mentioned is the pathetic lack of midi functionality - i.e. not being able to send out multiple midi ports / channels from one patch. There are ways around this that involve third party externals, but I must say this was the most disappointing thing for me - very limiting.

Is this in M4L or max/msp?

interesting!

Do you think this might be changed with the new max 6?

how hard is the routing with third party externals, what you using?

Not sure to go M4L or max/msp...

Cheers for reply!

This is not a limitation with Max/M4L but a limitation with Live itself, so until Live can handle internal and external multi midi routing it will not be solved, Max 6 or not.

Yep, it is a Live limitation, which I would also say is a M4L limitation. You simply have 'midiin' and 'midiout' in M4L for the one channel you are on. You certainly do not have this limitation in Max/MSP (or in fact most other DAW's). Totally agree that this is not Cycling 74's issue, it is Ableton's. No focus seems to have been put on midi - I wouldn't mind but it is not only for external gear, it's also for routing notes / controller signals etc to software instruments, plugins etc too. For the type of stuff I do, I actually could not use Live at all without a solution, so I endeavoured.

The bascis on the solution...

There is a set of third part externals (java objects) that allow very easy routing of UDP messages. So you send a message through UDP using your loopback port (127.0.0.1) from a M4L patch and use a receive UDP object in a totally different patch - doesn't matter what channel. Actually, it doesn't even matter if the receive message is in Live, Max or any other program as long as it can receive UDP messages.

In terms of going Max or M4L, I would go both! You kinda need Max to enable proper editing in M4L anyway (I think - I have used Max for years so already owned it). But download the Max trial and have a go. You have 30 days and I strongly suggest you go through all of the tutorials, no matter how painful it seems. If you are like me, you will see how versatile it is - for both audio and midi.

If you want details on the how to route internally, I will dig out all the relevant info and links. It took a lot of digging for me to find the solution, so would be happy to save people time. I didn't post before because I didn't think anyone else cared given the lack of info out there!

[luddy]

Just wanted to point out the obvious: Max standalone does not allow you to build devices that can be inserted into Ableton Live tracks and that talk to the Ableton Live API.

It's not true that you need Max standalone for proper editing; the editor is the same in both the standalone and M4L versions, aside from some small details that were added in M4L such as preview mode etc.

-Luddy

[trevox]

Firstly, note that all of this is totally independent of Live - absolutely nothing needs to be chosen as the input or output on any Live track unless you wish to feed a midi input using the midiin object or midiout using the midiout object. Within the patch, you can mix the data from either source.

Download the appropriate package for your OS from this website - either "Everything for Mac OSX" or "Everything for Windows":

http://cnmat.berkeley.edu/downloads

Extract the contents to your Cycling '74 folder (or any other folder you wish that is listed as a path in File Preferences).

In the max patch you want to send from, create an object called "js ocs-unroute.js /name" - replace "name" with whatever makes sense to call the message you are sending. There should be one input to this object. If you have more than one message you want to send from that patch, create an object called "js osc-unroute.js /name1 /name2", You should see 2 inputs now. Same deal for 3, 4, 5 messages etc... Link whatever messages you want to send to other patches/programs into the appropriate inputs.

Now in the same patch, create and object called "udpsend 127.0.0.1 XXXX", where XXXX is a port number of your choice (do a google search to find commonly used UDP ports and choose something different). Link the "js osc-unroute.js" object's output to this objects input.

You are done in terms of sending the message - now to receiving.

In the receiving patch, (note other programs can receive the message too, but this is specific for Max) create an object called "udpreceive XXXX" where XXXX is the port number you chose before.

Create an object called "osc-route /name" where "name" is the appropriate one you chose for that message. Link the "udpreceive" object's output to this objects input.

You will see one output. Similar to the sending object, you can choose more than one output and this will create more outputs in the object.

The outputs will now be the exact same message as the input from the sending patch.

A couple of notes...

I may have installed other externals needed for this solution, but I am pretty sure nothing else should be required. If it doesn't work, let me know and I'll look into it.

You may see people say you can use the standard Send and Receive messages in Max. While you can, it is ridiculously unstable and there are horrible delays. So unless the messages are not vital in terms of timing, you cannot really use these.

Really hope this saves people time and opens up more possibilities for people as it certainly has for me.

[trevox]

Just wanted to point out the obvious: Max standalone does not allow you to build devices that can be inserted into Ableton Live tracks and that talk to the Ableton Live API.

It's not true that you need Max standalone for proper editing; the editor is the same in both the standalone and M4L versions, aside from some small details that were added in M4L such as preview mode etc.

-Luddy

I stand corrected on the editing part - I've always had Max and wasn't sure. However, there are a lot of features not in M4L that can be used in Max as a standalone, but maybe not enough to fork out on it. Depends on the user I guess.

Your first point is right and wrong at the same time. While you cannot insert a patch saved in standalone Max, you can copy/paste from a Max patch into M4L, which means you can build a patch in Max and with little effort use it in Live. I did this with most of the patches I have developed over the past several years in Max. Some need slight tweaking in terms of the inputs it's receiving and where the outputs need to go, but on the whole, the programming is the same (assuming M4L "understands" the objects). One big pain is number boxes, knobs, faders, buttons etc that you may want to save the values of. In M4L you have the replace these with the "live." equivalent objects. You can copy one and select all the objects you want to change and do a kind of global replace though which is handy. Took a while to figure this out though!

[broc]

You may see people say you can use the standard Send and Receive messages in Max. While you can, it is ridiculously unstable and there are horrible delays. So unless the messages are not vital in terms of timing, you cannot really use these.

According to my tests the (maximum) delay is relative to Live's audio buffer size.

512 samples: ~12 ms
128 samples: ~5 ms

Unfortunaly there is no official documentation about this.
But it has been stated from developers that OSC will *not* behave better in general.

The basic problem seems to be that M4L devices on different tracks may run on different threads.
Thus any additional communication across devices is difficult to synchronize (or even impossible).

[luddy]

Your first point is right and wrong at the same time. While you cannot insert a patch saved in standalone Max, you can copy/paste from a Max patch into M4L, which means you can build a patch in Max and with little effort use it in Live. I did this with most of the patches I have developed over the past several years in Max.

Right, but I meant to point out the converse: one should not buy standalone Max thinking that they can create M4L devices in it. For that, you need Max for Live. Each of the products offers things that the other does not.

-Luddy

[trevox]

You may see people say you can use the standard Send and Receive messages in Max. While you can, it is ridiculously unstable and there are horrible delays. So unless the messages are not vital in terms of timing, you cannot really use these.

According to my tests the (maximum) delay is relative to Live's audio buffer size.

512 samples: ~12 ms
128 samples: ~5 ms

Unfortunaly there is no official documentation about this.
But it has been stated from developers that OSC will *not* behave better in general.

The basic problem seems to be that M4L devices on different tracks may run on different threads.
Thus any additional communication across devices is difficult to synchronize (or even impossible).

The delay has little to do with Live audio buffer. It is Max's scheduler that is the issue. Trust me, I tried at length and if you are spraying notes to various different patches using standard send/receive, it trips up all over the place. The same setup using osc works great. I trust real life tests over developers telling what something can and cannot do. If send/receive works for your needs, great as it's a lot easier, but if like me you require something a bit more accurate, osc work a thousand times better in real life.

An example of my real life test is triggering midi using an electronic drum kit to trigger a nord modular. I wanted to treat each drum within their own M4L patch and send out to different midi channel. Both send/receive and osc work fine if you simply hit a drum once. Now try a snare roll...

Send/receive patch sounds like a stammering drunk puking all over the place. Osc send/receive is a smooth roll.

No-one can convince me that send/receive is better than osc send/receive between patches within M4L as my real life tests prove otherwise. I could not write music in the manner I do within Live without osc send/receive.

[trevox]

Your first point is right and wrong at the same time. While you cannot insert a patch saved in standalone Max, you can copy/paste from a Max patch into M4L, which means you can build a patch in Max and with little effort use it in Live. I did this with most of the patches I have developed over the past several years in Max.

Right, but I meant to point out the converse: one should not buy standalone Max thinking that they can create M4L devices in it. For that, you need Max for Live. Each of the products offers things that the other does not.

-Luddy

Fair point!

[broc]

You may see people say you can use the standard Send and Receive messages in Max. While you can, it is ridiculously unstable and there are horrible delays. So unless the messages are not vital in terms of timing, you cannot really use these.

According to my tests the (maximum) delay is relative to Live's audio buffer size.

512 samples: ~12 ms
128 samples: ~5 ms

Unfortunaly there is no official documentation about this.
But it has been stated from developers that OSC will *not* behave better in general.

The basic problem seems to be that M4L devices on different tracks may run on different threads.
Thus any additional communication across devices is difficult to synchronize (or even impossible).

The delay has little to do with Live audio buffer. It is Max's scheduler that is the issue. Trust me, I tried at length and if you are spraying notes to various different patches using standard send/receive, it trips up all over the place. The same setup using osc works great. I trust real life tests over developers telling what something can and cannot do. If send/receive works for your needs, great as it's a lot easier, but if like me you require something a bit more accurate, osc work a thousand times better in real life.

An example of my real life test is triggering midi using an electronic drum kit to trigger a nord modular. I wanted to treat each drum within their own M4L patch and send out to different midi channel. Both send/receive and osc work fine if you simply hit a drum once. Now try a snare roll...

Send/receive patch sounds like a stammering drunk puking all over the place. Osc send/receive is a smooth roll.

No-one can convince me that send/receive is better than osc send/receive between patches within M4L as my real life tests prove otherwise. I could not write music in the manner I do within Live without osc send/receive.

Interesting. So apparently OSC is better at handling high data rates.
I've tested only the timing of single messages and found basically the same delay with both methods.