amounra

Sorry in advance, my anal retentiveness is showing...basically, I just can't stand seeing errors in the Max window.

When navigating LOM via js, I use a "finder" object as a single instance of LiveAPI object and then move it around to different paths to parse information. When diving into chains in a rack, and then using finder.goto('canonical_device'), Max complains about jsliveapi syntax errors. It will fill up the max window pretty quickly with a large set.

I've attached a Live set with a device I built for parsing parameters from nested racks that demonstrates this. (I built it for locking to parameters in a VirusControl AU, but the patch fires regardless of what's in the set as long as there is a Track named "Virus" in the set). If you install the .alp and then open the set and look in the Max window, you will probably see what I'm talking about.

Can someone confirm? I get this behavior on multiple machines, running 10.7 or 10.8, Live 9.1, Max6.16. Again, the contained patch does what it's supposed to do, but it would be nice to get rid of these errors (which are presumably happening because of some internal type issue in jsliveapi?).

If there's another way to do climb the LOM without getting the errors (obj.goto('up') doesn't seem to work in js), I'm all ears. All the error messages make it difficult to debug my set.

edit::grrr, won't let me attach .alp file, so I've put it here:

https://dl.dropboxusercontent.com/u/6044993/InvalidSyntax.alp

When navigating LOM via js, I use a "finder" object as a single instance of LiveAPI object and then move it around to different paths to parse information.  When diving into chains in a rack, and then using finder.goto('canonical_device'), Max complains about jsliveapi syntax errors.  It will fill up the max window pretty quickly with a large set.

I've attached a Live set with a device I built for parsing parameters from nested racks that demonstrates this.  (I built it for locking to parameters in a VirusControl AU, but the patch fires regardless of what's in the set as long as there is a Track named "Virus" in the set).  If you install the .alp and then open the set and look in the Max window, you will probably see what I'm talking about.

Can someone confirm?  I get this behavior on multiple machines, running 10.7 or 10.8, Live 9.1, Max6.16. Again, the contained patch does what it's supposed to do, but it would be nice to get rid of these errors (which are presumably happening because of some internal type issue in jsliveapi?).

If there's another way to do climb the LOM without getting the errors (obj.goto('up') doesn't seem to work in js), I'm all ears.  All the error messages make it difficult to debug my set.

edit::grrr, won't let me attach .alp file, so I've put it here: 

https://dl.dropboxusercontent.com/u/6044993/InvalidSyntax.alp


js-canonical_parent-gives-error-but-works

On further investigation, I discovered this only happens when backing out of the LOM from api.live_set.tracks[n].device[n].parameters[n] to api.live_set.tracks[n].device[n].parameters[n].canonical_parent.

I solved my issue by storing the api.live_set.tracks[n].device[n].parameters.id and reassigning it after the operation instead of trying to use canonical_parent, this doesn't give me a syntax error.

On further investigation, I discovered this only happens when backing out of the LOM from api.live_set.tracks[n].device[n].parameters[n] to api.live_set.tracks[n].device[n].parameters[n].canonical_parent. 

I solved my issue by storing the api.live_set.tracks[n].device[n].parameters.id and reassigning it after the operation instead of trying to use canonical_parent, this doesn't give me a syntax error.


js: canonical_parent gives error, but works.