max vs Live API vs java script

[Tone Deft]

I find I'm trying to do everything with max and not spending time learning the Live API or trying javascript to accomplish tasks. does anyone have advice on how to use these 3 tools and direct my time learning all this stuff? I'm a max n00b, took a week of classes a few years ago, I get by. I don't know javascript but at a basic level it looks like most high level languages but I don't know how to encapsulate java script, I assume it's easy. I watched a great video at www.max4live.info on querying the Live API objects to learn them, so I know where to start with that but i haven't taken the time.

any tips?

many thanks!

[julienb]

I find I'm trying to do everything with max and not spending time learning the Live API or trying javascript to accomplish tasks. does anyone have advice on how to use these 3 tools and direct my time learning all this stuff? I'm a max n00b, took a week of classes a few years ago, I get by. I don't know javascript but at a basic level it looks like most high level languages but I don't know how to encapsulate java script, I assume it's easy. I watched a great video at http://www.max4live.info on querying the Live API objects to learn them, so I know where to start with that but i haven't taken the time.

any tips?

many thanks!

http://groups.google.com/group/ableton-liveapi

[Tone Deft]

any other advice on which approach to use? this is still bugging me.

[amounra93]

I was able to accomplish pretty much everything that I need to do in Live just within Max, before M4L even came out. This was done by incorporating the previously mentioned Python hack that has been around for a while. It works very well. That said, I should tell you that m4l and its access to the API has made my setup work better, and quite a bit more elegantly.

As far as whether to use the Max API objects or js versions of the same, its really about your level of understanding. Both can accomplish about the same thing, just in a different manner. The Max objects themselves seem (to me, anyway) to be a little more stable, but perhaps not quite as fast. You probably won't notice either way, honestly, unless you are trying to do too much through the API in the first place, in which case I would say its a good idea to examine exactly what your objectives are, and maybe try to rethink them. Also, keep in mind the js stuff is still in beta.

Hope that helps

[pukunui]

We'd be interested in hearing ways we could make the js API stuff better in future releases, but it is not the case that this particular part of MFL is in beta. The way it works now is fundamentally the way it will keep working, and code that you write now in js will be supported in any future version of the product.

-A

[technog0d]

I was able to accomplish pretty much everything that I need to do in Live just within Max, before M4L even came out. This was done by incorporating the previously mentioned Python hack that has been around for a while. It works very well. That said, I should tell you that m4l and its access to the API has made my setup work better, and quite a bit more elegantly.

As far as whether to use the Max API objects or js versions of the same, its really about your level of understanding. Both can accomplish about the same thing, just in a different manner. The Max objects themselves seem (to me, anyway) to be a little more stable, but perhaps not quite as fast. You probably won't notice either way, honestly, unless you are trying to do too much through the API in the first place, in which case I would say its a good idea to examine exactly what your objectives are, and maybe try to rethink them. Also, keep in mind the js stuff is still in beta.

Hope that helps

Pukunui could probably very this... But, The way that i understand the Javascript functionality is implemented in M4L is that Javascript gets a lower priority thread. Basically, Live is considered to be in overdrive mode all of the time. In overdrive mode there are two threads. These threads get priorities. Supposedly Javascript gets the lower priority thread. This may mean nothing for the most part, but it is just a consideration.

Mike

[amounra93]

Yes, please verify....I'd really like to know the answer. It doesn't make a difference in my current situation, as I'm using js because its more compact....but it would be pertinent to other situations, for sure.

[pukunui]

Threading considerations are pretty much out the window when it comes to the API. There's no such thing as running the API in overdrive, as we always have to wait around to get notifications back from the Live process. In fact, running API code at low priority usually makes it perform much better, kinda like Jitter.

It depends what you want to do. On a small scale, there is probably no difference between patching and JS. Once you get out to observing large numbers of properties, and managing a lot of state, the advantages of a procedural text language like JS mean you will save a lot of time and heartache writing your API functionality in that way. I have also observed that JS API code loads faster than its patcher equivalent.

Cheers

Andrew

[technog0d]

Threading considerations are pretty much out the window when it comes to the API. There's no such thing as running the API in overdrive, as we always have to wait around to get notifications back from the Live process. In fact, running API code at low priority usually makes it perform much better, kinda like Jitter.

It depends what you want to do. On a small scale, there is probably no difference between patching and JS. Once you get out to observing large numbers of properties, and managing a lot of state, the advantages of a procedural text language like JS mean you will save a lot of time and heartache writing your API functionality in that way. I have also observed that JS API code loads faster than its patcher equivalent.

Cheers

Andrew

Thanks for the clarification. It definitely helps understand how things will react within M4L.

Thanks Again,

Mike

[Tone Deft]

As far as whether to use the Max API objects or js versions of the same, its really about your level of understanding. Both can accomplish about the same thing, just in a different manner. The Max objects themselves seem (to me, anyway) to be a little more stable, but perhaps not quite as fast. You probably won't notice either way, honestly, unless you are trying to do too much through the API in the first place, in which case I would say its a good idea to examine exactly what your objectives are, and maybe try to rethink them. Also, keep in mind the js stuff is still in beta.

Hope that helps

it helps, makes sense. thanks! maybe once I get my first project going with max I'll redo it with javascript. there were some things I couldn't do with just max, like get Live's quantize setting but I've been n00bing it back then.

[halley]

The real differences are in the interface itself.
It's really incredible how the same Object Model can be accessed in so many different ways.

If you put side by side:
Max Patch, JS LiveAPI code, Python LiveAPI code
they are all different and deal with things in different ways.

The bad thing is that Python LiveAPI seems to be the best one for performance
and has an understandable programming interface (properties, methods, objects
often require very little explanation), but (1) there's no real debugging (apart from logging) (2) even if is somehow supported there's no official documentation and similia (3) the facts that there's no real debugging and no real support/documentation are confirmed by the fact that Live Crashing is 'part of the development workflow' (if I'm missing some wonderful ways of managing python liveapi coding let me know, please.... in my humble opinion and experience even with simple mistakes Live simply crashes)

The JS LiveAPI is different from Python liveAPI. It seems that it'll be the supported/official way of doing a certain kind of things. The programming style is a bit different...

Let's make an example:
In JS LiveAPI every track has a solo property, that you can get, set and observe. Most of the interactions with the track object pass through one or more 'instances' of the one and only LiveAPI() object. You have one single callback per LiveAPI instance... etc, etc

In Python LiveAPI every track has the same solo property but there are a bunch of explicit functions: add_solo_listener, solo_has_listener, remove_solo_listener (and this are only for adding/removing/checking the callback function for solo property)
Sure the general programming interface of some objects is cluttered but in the end the code it's more readable. (at least it seems more readable to me, but I'd love to hear comments on this). In python there is the possibility to set a callback function (listener) for specific properties...

In MAX Patches everything it's different again, MAX programming interface it's another one... there isn't the generic LiveAPI object but the trio of Live.path, Live.object, Live.observer.
Sure this objects are designed to work inside the flow of messages of Max patches but sometimes I have the feeling that in some places a simple object coming from the Live Object Model would have been more readable in the patch, and more usable from people that is already using these concepts every day to make music.


In js you'll write something like this:

Code: Select all

var track_0 = new LiveAPI(this.patcher, track_0_callback, ["live_set tracks 0"]);

track_0.property = "mute";
track_0.property = "solo";
track_0.property = "arm";

function track_0_callback(args)
{
	switch(args[0])
	{
		case "mute":
			...
			break;
		case "solo":
			...
			break;
		case "arm":
			...
			break;
	}
}

or like this:

Code: Select all

var track_0_mute = new LiveAPI(this.patcher, track_0_mute_callback, ["live_set tracks 0"]);
track_0_mute.property = "mute";
var track_0_solo = new LiveAPI(this.patcher, track_0_solo_callback, ["live_set tracks 0"]);
track_0_solo.property = "solo";
var track_0_arm = new LiveAPI(this.patcher, track_0_arm_callback, ["live_set tracks 0"]);
track_0_arm.property = "arm";


function track_0_mute_callback(args)
{
	...
}

function track_0_solo_callback(args)
{
	...
}

function track_0_arm_callback(args)
{
	...
}

In Python you'll write something like:

Code: Select all

tracks = self.song().visible_tracks
track_0 = tracks[0]

if ( track_0 != self.song().master_track)
	track_0.add_solo_listener(self._on_solo_changed)
	track_0.add_mute_listener(self._on_mute_changed)

if track_0.can_be_armed == 1:
	track.add_arm_listener(self._on_arm_changed)



def _on_solo_changed(self):
	...


def _on_mute_changed(self):
	...


def _on_arm_changed(self):
	...

Ina Max Patch you'll connect a message to a Live.Path, then connect the output to a Live.object and a Live.observer, then connect the output of the Live.observer to the rest of the patch that acts as a callback function.

Am I the only one thinking that python interface is more readable?
Sure python interface has too much functions, but...

between something like:

Code: Select all

var track_0 = new LiveAPI(this.patcher, track_0_solo_callback, ["live_set tracks 0 solo"]);
track_0.property = "solo";

where the fact of assigning the 'solo' string to the 'property' property of a track...
means that the solo property is now observed and that the changes are notified to the function given during the creation of a generic LiveAPI object.... that in reality is a track object, but could change whenever you assign a different path to this same object... and what happens to the observed property/object... etc, etc. in other words, not straightforward...


and something like:

Code: Select all

track_0.add_solo_listener(self._on_solo_changed)

where you have at least two functions named after every observable property. so if you have an object with 20 properties you already have 40 functions, and this is only if you have two functions per property...


isn't there something like:

Code: Select all

track.1.add_observer(solo, solo_callback)

where you:
- navigate directly to an object. the object it's already there inside the song tree so there's no need (at least conceptually IMHO), to create a new one (see the totally misleading "new LiveAPI" instruction)
- add directly an observer with a function. the function is the same for every observable property, for every object that has observable properties. there's no need to have objects with a huge number of functions. there's no need to eventually learn the names of these functions if they appear to be named inconsistently
- the intentions of the code are readable. add an observer/subscriber to the solo property, notify changes of this property to the solo_callback function.





@amounra93
Python works very well because, even if the liveapi stuff that 'has been around for a while' is a hack, controller scripts are originally written in python.
I really don't understand what is that Ableton started supporting about this hack, it seems to me that they simply acknowledged it. If they started supporting we should have a bit of documentation and maybe a simple console window to do some simple debugging and maybe avoid some of Live Crashes.
I personally think that m4l and it's access to the API do not make things more elegant, maybe more supported but surely not more elegant (IMHO of course).

[amounra93]

I personally think that m4l and it's access to the API do not make things more elegant, maybe more supported but surely not more elegant (IMHO of course).

In all honesty, I couldn't continue to do everything that I'm doing in my Live set without the Python API stuff (er, I could, and probably will eventually, but I did all the work with LiveOSC, so I haven't ported that part yet, since it lives in a Max standalone that deals with my ReMote25SL). Also, there are some things (especially emulating ports and sending sysex to control surfaces) which I still can't do without Max in standalone mode. But for the stuff that happens inside M4L, I like being able to do it ONLY inside m4l. I guess that's what I consider more elegant, that I can do most of it in one place, i.e. Live. Programming was much easier when it was just in Max by itself: I had less crashes, and generally it took less time. But performance (especially timing) when using the same ports inside M4L is much better, and more consistent (until I hit the edit button).

Thanks for the examples. I'm not Python savvy, and have been living off of other's work for a while, but since delving into JS recently, I feel better armed to try to do some of the thing that I've always wanted to do purely inside of Python. Especially since most of the Control_Surfaces that I want to work with aren't hooked into the LiveAPI for m4l yet. Hopefully Ableton doesn't ever decide to close the door on those who have contributed to that part of the environment, as it is a very great tool. It is unfortunate there are not more debugging resources; having not coded in Python before, the painfulness of this hasn't become apparent to me yet. Not looking forward to it

[ST8]

For me the python api is still the only one im interested in. I can observe absolutly everything in the current live set (even with 150+ scenes) and there is no delay on adding / deleting tracks or refreshing everything. Its perfect for my uses.

As far as development goes, ive got a pretty streamlined working environment. I use logging over tcp to a console to get realtime error messages. As long as you dont break your base class live shouldnt crash when you mess up but you'll get errors from your child classes.

If you're python savvy check out http://monome.q3f.org/wiki/LiveControl for what im currently working on plus how i deal with logging and debugging. Plus ive updated LiveTelnet to work on OS X, that means you can dig about in the api from essentially a python console (http://monome.q3f.org/browser/trunk/LiveTelnet). I'm sure the ableton devs must have a special build of live with a python debugging console.

I think the ONLY thing that the python api is missing is a quick callback. All our work is currently limited to 100ms refresh (that includes parsing incoming osc) as the update_display function is called at that interval. If someone could be nice enough to add a function that was called say 10ms interval or something that was at least in time with the current live set tempo that would make much more possible (sequencers, drum triggers, etc, etc ...). I dont think that'll ever happen though.