amounra

Ok, so I'm finally getting around to the move....I really hate change. I've discovered a lot of broken patches, and chief among the cause so far is my extensive use of js for API linking.

Apparently, in current versions it is not optional to include a callback declaration in the creation of a new LivaAPI object, whereas before it was optional. Did I miss the memo? (and) Why must it be so?

This is problematic in several places (chiefly, because now I have to go through all my js scripts with a fine-toothed comb ;) ), but one of the main areas I see a real problem:

If you have multiple js API object's connected to the same control surface NotifyingControlElement that are in different patches, then open one of those patches in the editor (or switch preview states), the Python notification dict doesn't ever get updated during the change, and throws errors because its feeding an MXDCore function that doesn't have a valid target. That tends to break things internally. I consider it a bug (or, at least, an oversight), but understandable since we're not supposed to be playing with that stuff anyway.

One way to deal with this in the past was to exclude the callback argument from the new LiveAPI creation, but now apparently that's not possible.

Unfortunately, there is also no way for us (via Python) to figure out what callback belongs to which device (or it would be a little less caustic problem). I'm sure there's an internal function that belongs to MXDCore that can do this, but I've not been able to decipher it.

Ok, so I'm finally getting around to the move....I really hate change.  I've discovered a lot of broken patches, and chief among the cause so far is my extensive use of js for API linking.  

Apparently, in current versions it is not optional to include a callback declaration in the creation of a new LivaAPI object, whereas before it was optional.  Did I miss the memo?  (and)  Why must it be so?

If you have multiple js API object's connected to the same control surface NotifyingControlElement that are in different patches, then open one of those patches in the editor (or switch preview states), the Python notification dict doesn't ever get updated during the change, and throws errors because its feeding an MXDCore function that doesn't have a valid target.  That tends to break things internally.  I consider it a bug (or, at least, an oversight), but understandable since we're not supposed to be playing with that stuff anyway.

Unfortunately, there is also no way for us (via Python) to figure out what callback belongs to which device (or it would be a little less caustic problem).  I'm sure there's an internal function that belongs to MXDCore that can do this, but I've not been able to decipher it.

javascript-api-creator-changed-in-max6

I'm not able to reproduce this. I can create a LiveAPI object without a callback with no problem.

Ahhhh....Okay I did some more testing after you replied and it does indeed work for me as well with a new js. This behavior was happening to me in frozen files, and at some point I added a callback to the creator function and got things working. I'll have to do some more testing to find out the specifics (I have plenty of patches to refreeze in Max6, so I'll get back to you when I find out what is going on with this).

For the record, the message I'm getting in response to this, which runs fine in Max5:

finder=new LiveAPI(this.patcher, 'control_surfaces');

js: monolcd.js: Javascript TypeError: "control_surfaces" is not a function, line 109

js: error calling function bang LCD dissolved!

I just unfroze this attached, resaved it in max6, closed it, reopened it in max6, refroze it, and I'm still getting the same message.

Maybe something else is wrong w/my syntax? I know that this.patcher isn't necessary, but I was getting the same result without it.

edit:: in any case, glad that it's SUPPOSED to work!

Ahhhh....Okay I did some more testing after you replied and it does indeed work for me as well with a new js.  This behavior was happening to me in frozen files, and at some point I added a callback to the creator function and got things working.  I'll have to do some more testing to find out the specifics (I have plenty of patches to refreeze in Max6, so I'll get back to you when I find out what is going on with this).

js: monolcd.js: Javascript TypeError: "control_surfaces" is not a function, line 109
js: error calling function bang LCD  dissolved!

Maybe something else is wrong w/my syntax?  I know that this.patcher isn't necessary, but I was getting the same result without it.

edit::  in any case, glad that it's SUPPOSED to work!


I can confirm the crash if there is no callback. I had to add an empty dummy callback in some places I did not need a callback to avoid a crash:

var api = new LiveAPI (dummyCallback, "");

I can confirm the crash if there is no callback. I had to add an empty dummy callback in some places I did not need a callback to avoid a crash:
    var api = new LiveAPI (dummyCallback, "");


same here, have needed to provide a dummy callback in order to get these to work

Please send me code examples and patchers which cause crashes or seem to require "dummy" callbacks. PM is fine.

Please send me code examples and patchers which cause crashes or seem to require "dummy" callbacks.  PM is fine.

I'm testing this now, and it seems somewhat intermittent. I'm working with the same patch that I clipped to my second post, and by commenting different parts of the js out and running the init() function over again; sometimes there is an error, while sometimes not (even without making any changes). It seems to be timing related, but I can't determine the cause specifically.

Can you maybe have another look at this? Presumably, the patch I sent you didn't exhibit the same behavior on your machine? (you should get an error in the Max window whenever you instantiate it in a Live project).

For the record, I've experienced this with both Live 8.3 and 8.32, Max 6.05.

I'm testing this now, and it seems somewhat intermittent.  I'm working with the same patch that I clipped to my second post, and by commenting different parts of the js out and running the init() function over again; sometimes there is an error, while sometimes not (even without making any changes).  It seems to be timing related, but I can't determine the cause specifically.  

Can you maybe have another look at this?  Presumably, the patch I sent you didn't exhibit the same behavior on your machine?  (you should get an error in the Max window whenever you instantiate it in a Live project).

For the record, I've experienced this with both Live 8.3 and 8.32, Max 6.05.


http://mossgrabers.de/Software/M4L/Squaron.zip

You will see the following output in the Max window:

Squaron.js: Javascript TypeError: "" is not a function, line 32

If you replace it with a null you can crash Live and Max completely: new LiveAPI(null, '');

Download for example my Squaron from: http://mossgrabers.de/Software/M4L/Squaron.zip
Remove the "dummyCallback" from line 32
You will see the following output in the Max window:

If you replace it with a null you can crash Live and Max completely: new LiveAPI(null, '');


I can't even load that device without it crashing.

May we please have the unfrozen source files?

Seems that there was still the old version on my server. But means you could reproduce the crash :-)

Seems that there was still the old version on my server. But means you could reproduce the crash :-)
I updated the file.


Javascript API creator changed in Max6