Its been quite a few weeks since I’ve been able to spend some quality time on my synthesizer gear. And now that I learned that Ableton and Cycling ‘74 have released the latest version of Live 8 and Max for Live (“M4L”) this obviously calls out for a relaxing synth evening.
New features or enhanced features?
There are some pretty interesting new features added to M4L, the most outspoken is obviously accessing chains and the containing devices with the live rack devices. Funny enough I consider this more of an enhancement than a new feature. Personally I’m more curious about having access to Live’s protected samples right from within M4L through usage of the live.drop object. Being a Suite user I have quite a few samples at my disposal, and although I’m fairly fresh when it comes to using samples (using either Sampler or Simpler) I’ve already discovered that using samples can open up a whole new world.
And now that we can use M4L to its full potential when it comes to using Live’s samples, that should indeed open up a load of possibilities. As outstanding as I consider Sampler, one has to admit than when it comes to flexibility M4L should be able to out weight it.
Chain class; proof of a solid design model
I’m not the guy who gets excited about (new) abstractions and even though I’m familiar with the M4L.api.ListOfAbstractions patch (check your ‘Extra’ menu; this patch can be very helpful if you do heavily rely on abstractions yourself) I think that in the end you’re limiting yourself by relying too much on them. If you want to get the most out of M4L then your best bet is to become familiar with the basics. In particular the Live Object Model (“LOM”).
And the new chain class is basically proof of this. Without having used it even once I immediately knew how to use it by merely looking at the chart and the several references and relations its showing you. And this is also what I’d like to call proof of a very solid (and very impressive) design model. Designing something is one thing, designing it so that it can be expanded upon in the (near) future is something else indeed. Yet that is exactly what Ableton and Cycling ‘74 (“C’74”) did.
What makes this so impressive you may wonder? Simple; although having access to devices inside racks maybe a new feature; this feature is still fully compatible and compliant with the standards which were already set out. A good example of this is my LOM.Navigator M4L device. This device allows you to browse the Live Object Model and makes it easier to discover what specific properties and functions each object (‘class’) has. Guess what? Using the latest Live 8 and M4L versions it will also easily allow you to access devices inside a rack.
Even though I wrote this patch at a time when this wasn’t possible at all.
That is a solid design model for ya! And quite frankly I’m more impressed by that than any other new feature they managed to squeeze in.
Live Object Model; a quick look at the ‘Chains’ class.
If you look at the overall picture of the LOM at the top you’ll see a lot of lines, either solid or dotted and arrows and such. I’m not going into too much detail here (at a later time perhaps) but what you’re basically seeing is which path to use in order to access something.
For example; we want to access a chain. A chain is obviously only available in a rack. A rack is basically a Live device which sits on a track. And finally a track is part of your Live set.
That is the logic being put to use here. So, to use the right order: we start with the Live set. Which conveniently also happens to be available as a “root object” (see the LOM overview page for now) which is called live_set. That’s where we’ll start.
As you can see there is a solid line going to the “Track” section which is called ‘tracks’. The line ends in three separate lines. As you can see in the legend at the top right this indicates a list. In other words; this path can access one or more objects, and so we’ll need to pick one. Perfectly logical considering that a live set can contain one or more tracks.
Next we’ll see a similar line which goes to the “Device” section which is called ‘devices’. It’s the same kind of line and the same logic applies here. After all; a track can have one or more devices.
And now we’re entering new territory yet as you can see its basically more of the same logic being applied here. There is a dotted line going to the “Chain” section which is called ‘chains’. As before this line also ends in three separate lines. First the dotted line; this indicates that we’re dealing with an optional relation. Obviously not every Live device provides chains. And as you can see there is also a small 5 present which foot note says: “racks only”. Makes sense, no ?
Then we see a solid line called ‘devices’ which goes right back to the “Device” section. And this is how we can access a device in a rack.
New M4L issue: always name your rack chains!
Obviously this isn’t mandatory but as you may know chains will be called “Chain” the moment you simply drop in devices onto a rack. While this may make perfect sense for you when you’re using the rack (because you can immediately see which devices you’re dealing with when you expand the chain (by double clicking for example)) it’s a lot more tedious in M4L.
So my tip for the day: if you’re going to access chains, name them.
As you can see here I’ve setup a rack with 2 chains in it; and also named them. Chain one, called ‘comp’ only contains a Compressor device whereas the other chain, called ‘Tube’ contains 3: Dynamic tube, Flanger and Gate.
How to access these? Simple!
First we’ll need to access this device. Since its sitting on the first (audio) track its path should be very straight forward: “live_set tracks 0 devices 0”.
The first thing to notice is the new “can_have_chains” device property which is a boolean type used to indicate if we’re dealing with a rack or a regular device.
And as we can see in this screenshot of my LOM.Navigator this new property is easily picked up. So now we know that we’re dealing with a rack. Notice the ‘chains’ child in the screenshot ?
That is our ticket into the rack. Because the moment when we point a live.object to this class and ask for more information it will easily tell us all of its child objects. Which are all the chains in the rack.
Please see the patch I inserted below:
In this patch I’m basically picking up all the names of the available chains. I call this a little bit of a hack because I’m not even checking if the device actually has any chains (using “can_have_chains”) nor did I build in a fail save.
But I do hope it gives you some idea; I’m pointing to the rack device (‘live_set tracks 0 devices 0’) and ask it to give me all the chains (‘get chains’). The result is a list which looks a bit like follows: “chains id 7 id 8”.
Since I don’t need the, what I call, “object list descriptor” I’m using ‘zl’ to slice away the first item. So now I’m left with only “id 7 id 8”. In order to use these one at a time I’m using ‘zl’ again but this time with the ‘iter’ option. “zl iter 2” basically means that it should send out 2 items of a list at a time. And since my list contains 4 items I’ll end up with 2 “cycles”; one will give me “id 7”, next cycle I’ll get “id 8”.
And since that is precisely which is being send out by a live.path object I don’t have to mess with anything else and can basically send this directly into a live.object so that I can perform some task on it.
In this particular example I’m accessing the “name” property which is a common property for most classes, and also supported by the ‘chain’ class (see the reference). The end result? “name Comp” and “name Tube”.
Accessing the chain in the rack
Now that we have the chains its time to access their devices. Easy as pie. Then again, making pie can be quite a bit of work I suppose
If you check out that reference link I added above or simply check out the whole LOM diagram again you’ll notice that the “chain” section has a list relation called ‘devices’. In other words; the Chain class has a child called ‘devices’ which points to the Device class.
And in order to get, say, the name of all devices in my second chain (‘Tube’) I can basically re-use the patch I previously designed. And this is one of the reasons why you’ll never see me using abstractions. Its much easier to do it yourself. I already have a patch which can get all chain names, to go one step further all I have to do is make some very small modifications:
And here you have it!
As you may notice I’ve only changed the first two message objects. The first at the top now points to the second chain of the rack, the second message object now gets all the device ids by getting the ‘devices’ property.
The rest of the device is exactly left the same as the one I had above.
And the output of this patch ?
See the screenshot at the bottom of this blog post.
And there you have it!
I’m not going into further detail right now because the rest should be pretty straight forward. Now that you have access to a device you can simply do whatever it is you wish to do to a device.
Simply check out the reference for the Device class and you’ll have all the information you need.
I hear some people thinking… “What if you need to access a rack inside a rack ?”. Simple; recursion. Just re-use the patch I posted here and use that on one of the devices which id you got after you used the “get devices” property request.
In order to determine if the device is actually a rack all you need to do is to use the already mentioned “can_have_chains” property. If that property has a value of 1 you’ll now to be dealing with a rack.
I hope this post gives you some ideas as to how to use the new features. I’m very serious and honest when I say that this is my first attempt at using this feature. Its no magic and really; its also not because I’m a “M4L guru” or anything. Far from it!
The main reason I could do what I showed here is because I started out by getting my fingers behind the basics of M4L. In this case; by learning how the LOM model works and how you should read it. Once you’ve mastered that part there’s little which you can’t do!
Hope this gives some of you some ideas.
With MANY thanks to both Ableton & Cycling ‘74 by providing us once again with something plain out awesome!
To close, the screenshot I promised you above: