The Live Object Model LOM is the key to advanced m4l.

[steff3]

[ For JS: ]
Is there a method we can query and get to know when the LiveAPI is actually up running and accessible?

Something like a loadbang but that indicates that LiveAPI is now accessible. Here it seems that at the time of the jsloadbang the LiveAPI is not always accessible and it seems that the point in time when this is the case also depends on the liveset. So I wonder, when Live has to load lots of samples and so on, how to get that moment. It would be kind if Live you tell us when it is ready ....

thanks

best

[amounra93]

Sweet! I knew I saw that somewhere....thanks for pointing me to the right place. I was hoping there might be more documentation by now, but I think that will get me started.

Regarding the loadbang situation, that's also a problem I've encountered with the API (even when using the standard API objects outside of js). I was hoping that using the js object might solve some of those issues, but I guess not?

[steff3]

Well, no, seems like js-loadbang even happens before native MaxLoadbang - so even less chance ...

Also, the untyped structure of JS does not make it easier to handle that. With Java you could just check for null or something like that.

The most elegant thing IMHO would be if Live tells JS when it is ready ...

best,
Steff

[jayemell]

Is there a method we can query and get to know when the LiveAPI is actually up running and accessible?

You can check for an uninitialized LiveAPI object.
If you find that it's not accessible (yet) via a test on a live api object, then you could ping the state with a new Task() object.
When the task has found that things are ready to go then you can kill it.

...Just woke up, so this might need some more thinking after I've had coffee.
jml

[amounra93]

Keep us updated....I'm trying to figure this out. I spent a lot of time scripting last night on something that worked only to find out that alas none of the API stuff gets loaded at patch init. Still, I like the possibilities of working with js a lot, it adds a whole new level to Max.

Is there a way to assign variables in java via a function, but have them accessible globally throughout the script (instead of just locally within the function)?

I was also trying to figure out a way to refer to refer to api.objects from outside the script...i.e. I want to assign a variable to a live_set and then have a message from an inlet refer to this variable and then perform some method (specifically ".call") from it. It seems straightforward, but I can't figure out how to do it.

Is there a way to create several live_sets inside an array? (this would solve my problem above, I think)

Thanks for help.

[steff3]

[quote="jayemell"][quote="steff3"]Is there a method we can query and get to know when the LiveAPI is actually up running and accessible?[/quote]

You [i]can[/i] check for an uninitialized LiveAPI object.

jml[/quote]

Thanks for your reply ... Well, I am not that savvy in JS (just started a couple of days ago), so what is the return value? on what to check? (If I print it out it is <undefined> - but is that on what I have to check. In Java I have null, in Objective-C nil - what do I get from JS?

thanks ...

best

[jayemell]

Here's some pseudo code (totally un-tested):

Code: Select all

var check = new Task(check_on_api);
check.interval = 300; //millis interval... rate at which to check on the api
var api = new LiveAPI(this.patcher, "live_set");

function loadbang()
{
	check.repeat;
}

function check_on_api()
{
	if(!api)  //---this might need to be more specific in some way
	{
		post("api is not loaded yet\n");
	}
	else
	{
		if(check.running)
		{
			check.cancel();
		}
		else
		{
			post("this should never happen.\n");
		}

		post("api has now loaded\n");
	}
      
}

In Java I have null, in Objective-C nil - what do I get from JS?

You get "undefined".
I have to get to bed, but hopefully this will be useful.

jml

[amounra93]

So, I'm at the end of my js exploits with the Launchpad, and I'm trying to get this init thing to work using a task, as jayemell suggested earlier. Having a bit of trouble. For whatever reason, .cancel is not canceling. Am I doing something wrong here, or misunderstanding what is going on? I've used cpost instead of post so that I can view what's going on when the plug is loaded in live and Max editor isn't open, it seems more dependable and absolutely necessary for some things. Just open console to see whats going on.

Code: Select all

var check = new Task(check_on_api);
check.interval = 1000; 

function loadbang()
{
   check.repeat();
}

function check_on_api()
{
    var api = new LiveAPI(this.patcher, "live_set");
    cpost("api id is: ", api.id, "\n");
    if (api.id=0)
   {
      cpost("api is not loaded yet\n");
   }
   else
   {
      if(check.running)
      {
        cpost("check cancel");
        check.cancel();
      }
      else
      {
         cpost("this should never happen.\n");
      }

      cpost("api has now loaded\n");
   }
     
}

Any ideas? I'm thinking simple recursion in a loadbang is my next move, but that seems dangerous somehow...

[amounra93]

Still curious why that wouldn't work, but I figured out something else....I'll post it tomorrow or the next day when I get some time to tidy up the rest of the code if anyone is interested. There's a lot more going on now in my script than just asking if the API is up, so I don't know how much help it will be without a little in depth examination.

Now I'm wondering how to best go about repolling the API when a device gets disconnected and then reconnected. It seems like constantly asking the API whether or not a device is there is going to cause timing problems, but maybe not. I can't think of another way to do it right now, though. If anyone has any ideas....

Ive found that scripting in the Max editor is very uncontrolled. I'm having to save a patch and reopen it every time I edit it for things to work right, and even then it only works half the time. Also, I was hoping js would allow me to work in the editor with less constraints (read: bugs) but not really so far. In fact, it might be worse. Still, it works in Live just fine as long as I never open Max to edit anything. As soon as the editor has been opened, though, latency gets all messed up and other craziness usually happens (I'm getting a lot of stack overflows, presumably from timing problems with the API not being open...even with the script I just built, which prevents anything from happening until it does).

[jayemell]

For whatever reason, .cancel is not canceling. Am I doing something wrong here, or misunderstanding what is going on?

although i'm not sure what you're trying to do here, you are attempting to set the live api.id to zero.
instead i think you want to use the comparison operator (==)

so instead of

Code: Select all

if (api.id=0)

i think you want a test such as:

Code: Select all

if (api.id == 0)

anyway... this portion of m4l is still in beta; period.
i would not recommend getting too deep into these dynamic notifications, but instead following the advice of andrew early on in the various conversations we've all had about this which is: cache early and thoroughly. use for loops to populate local (or global) vars for your set and base that all on the init of your live set.

the more callbacks you have being dynamically created the slower the entire process becomes and the less fun you'll have actually making things. i don't think the LOM is meant as a way to get the "most advanced control out of live", but rather a way to ensure you have some communication between live and max that will allow for case-dependent notifications. relying on dynamic reallocation of the object tree is a bit strange and could cause major confusion w/r/t debugging.
just my opinion of course; i haven't found a need for it.

re. the js editor:
don't use it. why would you?
just turn autowatch on and use any number of your favorite external text editors:

Code: Select all

autowatch = 1;

remove it when you're done editing.

re. printing:
the easy kludgy way:
put a print object somewhere in your patch where it's exposed and double-click on it.
the max window will open up and show you all the messages. in my experience cpost doesn't give me everything i need... but i've also found that the LOM seems to be rebuilt when i save a .amxd file, so I mostly just print out in Max as I have both Live/Max open.

re. patching in m4l:
i would highly recommend doing patching while the transport is stopped currently, even thought it shouldn't matter too much.
i've gotten quite a bit of mileage out of this simple method.

jml

[amounra93]

instead i think you want to use the comparison operator (==)

yeppers, that was probably it.

use for loops to populate local (or global) vars for your set and base that all on the init of your live set.

that's pretty much what I'm doing at present...I'm just trying to make sure the api is up before its accessed...loadbang's happen (in large sets) before the API is accessible to constructors.

the more callbacks you have being dynamically created the slower the entire process becomes and the less fun you'll have actually making things

my opinion is the same...I am using the js API object ONLY to map calls/callbacks to the Launchpad, whose features aren't as accessible through MIDI alone. I set up all of the constructors/callbacks at the load of the plug, and they are static until the control_surface disconnects or until the plugin is reloaded/saved.

re. the js editor:
don't use it. why would you?

Sorry, should've been more specific. I was refering to the Max editor. Editing js within it isn't a problem (I'm autowatch savvy). Its just having the file open in two places, I think (Max and Live). Often times when saving a js and not reopening the m4l patch itself, old paths are still in place, so things get duplicated. It's more a matter of properly understanding what's going on under the hood, which I presently don't.

put a print object somewhere in your patch where it's exposed and double-click on it.

That's a good idea. I read that somewhere and forgot about it. That's obviously the best option, thanks for mentioning it.

Regarding play state while editing: my experience is the same. I've experienced major problems without adhering to that simple rule. But it makes no difference with latency....once the Max editor has been accessed in an open set, latency is botched until I reopen Live/M4l. Usually in the order of 100-150 ms. Its acceptable, but it makes it very hard to figure out the difference between the natural latency of an open plugin, because in order to edit the plug, the latency is incorrect.

Thanks again for the advice, it has been very helpful. All in all I'm excited to be learning all this javascripting stuff, it is another awesome tool to manipulate things inside the environment Proper documentation would make the whole thing easier, but I have no expectations, and do understand that its beta.
That's the main reason I've been posting on here so much: I really don't know what I'm doing, and it makes it a lot easier to collect the advice of those who have more experience with js and perhaps more information than what I have access to.

Cheers


EDIT::

Here's the fruits of my labor so far:

http://forum.ableton.com/viewtopic.php?f=35&t=131457

[jayemell]

hi there again;
i know that this is an old thread and you've probably advanced past this point by now, but i rely on the message object's right inlet (the set inlet) heavily for displaying info in m4l.
i would recommend using it to watch the output of objects in a m4l device.

jml