devnull

LiveAPI. Problem; doing my head in. Your help appreciated.

The code I'm working on isn't as brief or pointless as shown below, but it's not far off. The problem is, my for loop doesn't always complete; I get an unpredictable number of iterations.. 

var observers;

function bang()
{
    observers = [];
    var o = new LiveAPI( callback_tempo, "live_set" );
    observers.push( o );
    o.property = "tempo";
}

function callback_tempo()
{
    for( var i=0; i<100; i++ )
        post( "Iteration", i, "because foo bar.\n" );
    
    post( "Done." );
}

LiveAPI. Problem; doing my head in. Your help appreciated.
The code I'm working on isn't as brief or pointless as shown below, but it's not far off. The problem is, my for loop doesn't always complete; I get an unpredictable number of iterations.. 


LiveAPI. Problem; doing my head in. Your help appreciated.
The code I'm working on isn't as brief or pointless as shown below, but it's not 

sporadic-erratic-termination-of-code

Example result, could be any number of iterations:

js : Iteration 0 because foo bar.
js : Iteration 1 because foo bar.
js : Iteration 2 because foo bar.
...
js : Iteration 8


My actual code is creating simple objects on each loop iteration. When I trace the collection of objects it's clear they aren't all being created. I've tried deferring the meat of the function deliberately by way of sending a call out of the [js] object, through a [deferlow] and back in to the [js] object, but it makes no difference.

Can anyone suggest why this might be happening?

outside of the bang function into global scop, so they won't get freed.

observers = [];

outside of the bang function into global scop, so they won't get freed.


observers is declared in global scope above the bang function (no?). If I trace observers after the loop failure, I can see it's still valid (apparently). If I change the tempo in Live, the callback still fires. Results vary, but generally the callback terminates prematurely at least 2 or 3 times before it begins to behave properly.

In case it's relevant, my entire script is about 1500 lines. I have autowatch=1. The problem tends to occur predictably following a save of the JS file. I have several variables declared in global scope but very few of them are being initialised there; only the ones which are to hold a constant value; the rest are being initialised from within bang(), or other functions, as required.

I have a button attached to the first (and only) inlet of my [js] object so I can bang it manually. I also have a loadbang() function which does nothing but call bang().

Occasionally it seems that the compilation of my JS file is not being handled properly. Output to the max console will show some messages which correspond to the previous version of my script, before I saved it.

Re-saving the patcher itself doesn't help.

ableton API will not be ready on loadbang. use live.thisdevice to start initialization

Actually I was using [live.thisdevice] to bang my [js] before I switched to loadbang() to see if it might help to diagnose the problem. Unfortunately the problem persists either way. Most of the time, neither are relevant anyway; the device is already loaded since hours ago; I simply save my script, wait a moment to give max a chance to reload it, and then manually bang it with the button..

..At that point, my bang function runs and executes a few iterations of the for loop before it appears to run out of time(?) or stack space(?) and curtails the loop in favour of executing subsequent parts of my script instead. There are no reported errors in this process.

From there, if I do nothing but hit the bang button again, the same thing happens but I might get a few more iterations out of the loop before it's cut short. Perhaps 8 or 12 iterations on the first bang; maybe 40 or 60 iterations on the second bang.

Repeating this process eventually yields the proper number of iterations...but of course I need to nail it on the first run every time to initialise my device properly.

I hope I can get to the bottom of this as it's brought several weeks of work to a screeching halt.

Sporadic / erratic termination of code