M4L Observer Limits?
Hello All,
So I just downloaded and installed Max For Live Beta along with Ableton Live 8.1 and have begun working through some patches that I'm planning on using.
One patch is essentially creating a grid that displays clip names and play status a la the APC clips grid. I've built buttons to navigate up, down, left, and right through the Ableton session, but I've noticed that with a few (8-16) instances of a subpatcher that observes clip name and play status the main patcher becomes very lagged - ie, it takes somewhere between 0.5 and 1 second to update the grid.
I'm wondering if this is reflective of some limitation of M4L in that it cannot handle too many calls to the API inside of one patcher, and, if so, if there is any way to poll the API more efficiently for large pools of data.
Any help greatly appreciated!
Show us the patch.
-A
Patch is attached.
The groups on the bottom half are what I'm using to monitor the clip information. Each one receives a nav message consisting of a track/scene index, then updates the call to the LiveAPI accordingly, resetting an observer to monitor play state changes and getting the track name, color (disabled), and play status.
The four navigation buttons at the top allow you to scroll through an Ableton session and display the corresponding clip information. Note the rather pronounced lag time between pressing a navigation button and when the clip information is updated.
Hopefully you can see some egregious error that is causing the patcher to run so slowly.
Here's my 2 cents
- API access in the editor is much slower than API access in an MFL device. As a device, I can sorta live with the refresh rate of this device. It's not awesome though.
- Calls to live.path are slow. The more you can cache these the better.
- I notice you have an API js object in there (with no script in it). We'll have docs for using that in the installer on Monday, and I expect you'll find it performs a bit better for situations like this.
-A
Good to hear - I've begun testing out the API access in javascript already. I didn't include these scripts with the patch I uploaded just to simplify the issue I've been having.
I've been pretty pleased with the performance of calls to the API in the javascript environment, and I think that utilizing this along with some smarter coding will allow me bump up my performance a little more.
Anyway, back to another question I had: I'm under the assumption that the APC-40 is illuminating its buttons by accessing the API, and it is able to update its states for a very large matrix of clips very quickly.
Is the slowness seen in my patcher an inherent limitation of accessing the API in the Max for Live environment, and, if so, are there any ways to increase efficiency in communicating with the API or access the API from any other environment?
Also, thanks for all of the help in the previous reply. I'm not trying to ask too much - just curious about the guts of the live API.
My js APC40 scripts are performing just as fast as anything I see in Live.
It's still early days. We're trying to make every thing as stable as we can. Optimize last, as they say.
As I mentioned, the live.path calls are your bottleneck. The way to do this in JS is to create an array for the entire clip matrix of your set, with callbacks for track and clip addition/clip firing etc. Then when you move your grid you are only moving a reference to something which is already in place.
-A
It's gonna take me weeka to understand a word that you just said Andrew but i'm gonna get there.... The APC40 rocks, it could just admittedly rock better!
I want to change the display behaviours of the clip launch buttons to indicate whether the clip has a follow action = green, is looped = orange, or will stop at it's end = red...
Then it's a simple matter of selecting a shift key like the stop all button and the clip launch button to change it's status thereby being able to switch a clip between looping, following or ending...
I have a lot of work ahead of me but it will change the way i use live considerably to be able to split tracks into section and then perform loops on the fly without having to worry that a follow action is going to cut in....
Trouble is i've not seen anything yet that mentions observing follow actions, or am i looking for the wrong terminology?
Cheers
D
Andrew,
Thanks for the help - I'm going to get digging around in js mode to see if I can't make my patcher a bit leaner, meaner, and more efficient. Since there isn't any documentation for the API access in js yet, do you think you could send me a bit of example code to get me going?
Thanks
Andrew
Here's a bit of a tease. This script observes all of the buttons and controls on an apc40
// observe apc40
// andrew@cycling74.com
function observe_apc40()
{
var apc40_view = new Array();
for (j=0;j
{
apc40_view[j] = new LiveAPI(this.patcher, callback, "live_set control_surfaces 0 controls " + j);
if (!apc40_view[j])
{
post("no api objectn");
return;
}
apc40_view[j].property = "value";
apc40_view[j].name = apc40_view[j].get("name");
}
outlet(0,"done");
}
function callback(args)
{
outlet(0,this.name + " " + args[1]);
}
Wow - forum code formating sucks
There's some more stuff in this thread
Should be enough to get you going
-A
Thanks again Andrew,
I've been dabbling in the code that you've posted a l
ink to for a little while now, and I'm making a fair amount of headway towards my eventual goals.
BUT
And this may sound a large bit noob here, but what exactly is a callback function? I've seen a little bit how they work in the context of the code you've shown, but I'm a little uncertain as to how to incorporate it into my project.
How would I use callbacks to update an array of all clip_slots if they are playing, not playing, or triggered?
Thanks again
Andy