Josh Ball

I've been experimenting with observing properties with Javascript, I'm calling a function every time the selected track changes to update an observer on 'live_set view selected_track view' - 'selected_device'. Every now and then I get an error message that reads: 

typedmess: api_handlemessage: corrupt object

And occasionaly I get an invalid object message occur that is similar.

When I get the corrupt object message the device stops working completely.

I'm thinking it's some kind of memory corruption due to an observer already being connected so changing the path for the API object causes some kind of strange behaviour, but wondering if anyone can confirm what's going on here, and how I can get around this problem.

I've been experimenting with observing properties with Javascript, I'm calling a function every time the selected track changes to update an observer on 'live_set view selected_track view' - 'selected_device'. Every now and then I get an error message that reads: 
typedmess: api_handlemessage: corrupt object
And occasionaly I get an invalid object message occur that is similar.
When I get the corrupt object message the device stops working completely.

I'm thinking it's some kind of memory corruption due to an observer already being connected so changing the path for the API object causes some kind of strange behaviour, but wondering if anyone can confirm what's going on here, and how I can get around this problem.



I've been experimenting with observing properties with Javascript, I'm calling a function every time the selected track changes to update an

js-in-max-for-live-live-observer-issues-memory-corruption

Getting the exact same. Were you ever able to get to the bottom of this?

I think what might be happening is that the LiveAPI object and its callback are keeping each other alive. Setting the 

 field of the LiveAPI object to the empty string (not 

!) removes the observer and allows both to be GCed. This seems to have resolved the problem for me.

Some more background on this problem on the LiveAPI object and its callback retaining each other can be found at 

https://cycling74.com/forums/how-to-destroy-a-liveapi-object-instantiated-in-js

I think what might be happening is that the LiveAPI object and its callback are keeping each other alive. Setting the property field of the LiveAPI object to the empty string (not null!) removes the observer and allows both to be GCed. This seems to have resolved the problem for me.

Some more background on this problem on the LiveAPI object and its callback retaining each other can be found at https://cycling74.com/forums/how-to-destroy-a-liveapi-object-instantiated-in-js .

I can't actually remember as it's been a while, I did end up solving this and some other JS problems with observers. I seem to remember the problem was to do with API objects being kept alive and then overwritten and corrupted. I'm not 100% how the GC works in Max For Live but someone did say JS objects are really low priority when it comes to the API, so often things get left and then if the function is run again it messes things up.

Using delete at the end of functions in JS when dealing with the API definitely helps me keep things clean, I do normally set things to null but will try an empty string next time something like this comes up.

I can't actually remember as it's been a while, I did end up solving this and some other JS problems with observers. I seem to remember the problem was to do with API objects being kept alive and then overwritten and corrupted. I'm not 100% how the GC works in Max For Live but someone did say JS objects are really low priority when it comes to the API, so often things get left and then if the function is run again it messes things up.

Using delete at the end of functions in JS when dealing with the API definitely helps me keep things clean, I  do normally set things to null but will try an empty string next time something like this comes up.


JS in Max for Live, live.observer issues - memory corruption?