Reading the Live Object Model (LOM)

Michael TerrenMax for Live, noisemakerLeave a Comment

Almost everything in Live can be controlled using Max for Live. Each one of these things that can be controlled is called an object. Every parameter, every device, clip information, transport information, colours, viewing information… they’re all objects that Max for Live can handle. These are organised into a big hierarchy, and this is shown in the Live Object Model (LOM). The LOM comes with Max—to get to it type ‘LOM’ in the search bar at the top-right of Max 7, and you’ll find the article entitled “LOM – The Live Object Model”.


There are two steps to controlling objects in Max for Live: find the path, then call the function or get/set/observe the property. Let’s start with finding the path.


The LOM has lots of arrows pointing to the kinds of objects there are in Max for Live—these arrows denote a path. Each of these arrows have their own name, so ‘tracks’, ‘master_track’, and ‘return_tracks’ all denote different paths. In order to control one of these objects, we need to establish a path to that object. Say, for example, we wanted to control the panning of a track using Max, we can follow the arrows to get to the ‘panning’ object, which happens to be a MixerDevice.

ObjectModel panning highlighted

We can see it starts at Song (live_set), goes through Track (tracks), into MixerDevice (mixer_device) and then to panning. Therefore, the path to get to panning is: live_set tracks mixer_device panning. Well, not quite. Which track are we changing the panning for?

Notice that the ‘tracks’ path on the LOM has a flared ending—it looks like three lines branching off to join the ‘Track’ object. What this means is that we have to tell Live which track in particular to interact with, and we do this by giving it a number. Live gives numbers to each track, as seen on their track activators:

track activators

When using numbers in paths, Max always counts from zero. I won’t lie, this can get confusing. The first track in Live (track 1 on the track activator) would be called ‘tracks 0’ in the Max for Live path. The 13th track in Live would be ‘tracks 12’ in the path, etc.

So if we wanted to change the panning of the first track in Live, our path is: live_set tracks 0 mixer_device panning

live path

To use this path, we put it into a message (shortcut ‘m’) and into a live.path object, with the word ‘path’ before it. The live.path object converts the path into an ‘id’, a number that Live uses to identify that particular object. From the live.path object, the second outlet goes straight into the live.object. Once you’ve done that, click the message to give the path to the live.path, and then to the live.object. Better yet, put a ‘live.thisdevice’ object and connect its first outlet to the message. All this does is whenever you load up this Max for Live device, it’ll send a bang once it’s done loading, so the path is sent properly when loading the device up.

One more useful thing about paths: you can get the path of the Max for Live object you’re currently working on, using the path ‘this_device’. This will get you a path equivalent to ‘live_set tracks x devices y’, where x and y are whatever track or device your M4L device is on. We can even just get the track number using the path ‘this_device canonical_parent’. This is very useful! The patch below shows these paths getting converted into an id and back into a path, thus showing which track and device this Max for Live device is on.

this_device canonical_parent

If we only wanted to change the panning of the track that has said Max for Live device on it (and that track happened to be track 0) then these two paths are the same:

live_set tracks 0 mixer_device panning this_device canonical_parent mixer_device panning

This gives you the freedom to move your tracks around without having to rewrite their paths.

Functions and Properties

The bottom part of the LOM, below the diagram, is an exhaustive list of everything that can be done to every object in Max for Live. It groups these by their object type (Tracks, Devices, MixerDevice, etc). In each of those are further subgroups: Functions and Properties. Functions and properties are the two main types of thing you can do to objects in Live.

A function is something that you do to an object. Functions are carried out using the word ‘call’, followed by the name of that function. This goes into the ‘live.object”s first inlet. One of the most popular functions is ‘fire’, when you’ve set your path to point to a clip (for example, ‘live_set tracks 0 clip_slots 0 clip’ points to the first clip of the first track) calling the ‘fire’ function fires that clip.

call fire

A property describes the object’s actual state. There are three ways to use properties: get, set, and observe. Not at all properties can be got, set or observed—the LOM will specify how you can access each property. To ‘get’ a property, the word ‘get’ followed by the name of the property. For example, you might want to get the minimum and maximum possible values of a parameter.

get min get max

‘set’ allows you to directly set the value of a property to a new one. In the picture below, a toggle in Max mutes or unmutes the first track.

track activator toggle

live.object is fine for setting a value once in a while, but it doesn’t work well when changing values very quickly. That’s where live.remote~ comes in. live.remote~ sets values at sample rate, so 44100 times a second or more. This is great for changing parameters over time—for example, I have a sine wave at 2 Hz changing the panning of the first track here—but it can be expensive on the CPU.

live.remote~ lfo

Finally, we can observe the value of a property. This is like ‘get’, but it automatically ‘gets’ whenever the property changes. You do this with the ‘’ object. One use for this might be seeing which parameter you have currently selected. In the example below, I’ve used the selected parameter to then ask another live.object for the name of the parameter.

observe name

In summary:

functions and properties


I hope this has demystified at least some of how you can convert the wealth of knowledge that is the LOM into usable Max for Live patches. There really is a lot you can do, and while this post only scratches the surface, I’ll be going a lot further in depth into the Live API over the coming weeks.

Michael TerrenReading the Live Object Model (LOM)

Leave a Reply

Your email address will not be published. Required fields are marked *